linux-kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Dec 2013 10:15:18 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: 

This had been posted way way back:  https://lkml.org/lkml/2013/1/16/696

and the discussion about it was:
 - If there are no uses of v2, then why not rip out the support for it.
   [b/c the work for it would be in the networking code and I am still
    hoping that will be done?]
 - Why not do all of this in the toolstack. Enforce that the guest
   can only use v1 ".. if the backend isn't going to make use of them."
   (Matt).
   I am not sure how one would set up the plumbing to properly figure out
   whether the backend (say a driver domain) would communicate to hypervisor
   or XenBus that it is going to use v1 only if it has not yet started.
   (It would not have started b/c the guest hasn't started yet).

   My thinking is that once the frontend and backend start using the
   esoteric features of v2 we can rip this patch out. And also implement
   the proper code for PVHVM/PVH to actually use v2 grants.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/