linux-kernel - Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46EED6A5.4080109@codemonkey.ws>
Date:	Mon, 17 Sep 2007 14:33:57 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Anthony Liguori <aliguori@...ibm.com>,
	kvm-devel@...ts.sourceforge.net, Avi Kivity <avi@...ranet.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

Jeremy Fitzhardinge wrote:
>> I'm starting to lean toward just using 0000.  If for no other reason
>> than the hypercall space is unsharable.
>>     
>
> Well, it could be, but it would take affirmative action on the guest's
> part.  If there's feature bits for each supported hypercall interface,
> then you could have a magic MSR to select which interface you want to
> use now.  That would allow a generic-interface-using guest to probe for
> the generic interface at cpuid leaf 0x40001000, use 40001001 to
> determine whether the hypercall interface is available, 4000100x to find
> the base of the magic msrs, and write appropriate msr to set the desired
> hypercall style (and all this can be done without using vmcall, so it
> doesn't matter that hypercall interface is initially established).
>   

The main thing keeping me from doing this ATM is what I perceive as lack 
of interest in a generic interface.  I think it's also a little 
premature given that we don't have any features on the plate yet.  
However, I don't think that means that we cannot turn KVM's PV into a 
generic one.  So here's what I propose.

Let's start building the KVM PV interface on 4000 0000.  That means that 
Xen cannot initially use it but that's okay.  Once KVM-lite is merged 
and we have some solid features (and other guests start implementing 
them), we can also advertise this interface as a "generic interface" by 
also supporting the signature on leave 4000 1000 and using the MSR 
trickery that you propose.

As long as we all agree not to use 4000 1000 for now, it leaves open the 
possibility of having a generic interface in the future.

Regards,

Anthony Liguori

>     J
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   

-
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/