Hi, I am currently working on hypercalls from HVM guests. I started with a set of Intel patches posted to xen-devel last September. I currently have code running for both 32-bit and 64-bit HVM guests running on a 64-bit hypervisor. I am curious why none of the original patches were accepted, and what I might need to do to make them acceptable. Is other work being done in this area that hasn''t been submitted? Should I submit my version of the modified patches as is? The following list summarizes the changes. Hypervisor changes: o Add vmexit handling for the VMCALL instruction. This includes adjustments to hypercall arguments due to 32-bit vs. 64-bit calling conventions. o Modify copy_to_user/copy_from_user to use hvm_copy for HVM guests. o Modify grant table setup to properly map the grant table shared data for hvm guests. o Provide alternate headers for compiling 32-bit HVM guest code to interface with a 64-bit hypervisor. Many of the hypervisor structures used for hypercalls vary between 32-bit and 64-bit guests. Dom 0 changes: o Modify HVM building to properly map in a xen start info page and the shared info page for event channel notifications. o Add a virtual PCI device to QEMU to facilitate event channel handling. Dom U (HVM) driver changes: o Modify grant table setup for HVM guest code. o Modify event channel handling to interface with an unmodified Linux kernel running as an HVM guest. o Make misc xen support available as a loadable module. Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Steve, Nice to see you work on this item. I am implementing the HVM guest para-driver(VBD/VNIF). The hypercall is part of the necessary infrastructure. It will be good to see your modified patch and have more discussion. Best Regards Yu Ke Intel Open Source Technology Center Steve Ofsthun wrote:> Hi, > > I am currently working on hypercalls from HVM guests. I started with > a set of Intel patches posted to xen-devel last September. I > currently have code running for both 32-bit and 64-bit HVM guests > running on a 64-bit hypervisor. > > I am curious why none of the original patches were accepted, and what > I might need to do to make them acceptable. > > Is other work being done in this area that hasn''t been submitted? > > Should I submit my version of the modified patches as is? > > The following list summarizes the changes. > > Hypervisor changes: > > o Add vmexit handling for the VMCALL instruction. This includes > adjustments to hypercall arguments due to 32-bit vs. 64-bit > calling conventions. > > o Modify copy_to_user/copy_from_user to use hvm_copy for HVM guests. > > o Modify grant table setup to properly map the grant table shared > data for hvm guests. > > o Provide alternate headers for compiling 32-bit HVM guest code to > interface with a 64-bit hypervisor. Many of the hypervisor > structures used for hypercalls vary between 32-bit and 64-bit > guests. > > Dom 0 changes: > > o Modify HVM building to properly map in a xen start info page and > the shared info page for event channel notifications. > > o Add a virtual PCI device to QEMU to facilitate event channel > handling. > > Dom U (HVM) driver changes: > > o Modify grant table setup for HVM guest code. > > o Modify event channel handling to interface with an unmodified Linux > kernel running as an HVM guest. > > o Make misc xen support available as a loadable module. > > Steve_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steve, Interesting subject - I must have missed the September patchset... I''ve been thinking a lot about para-virtualized drivers for HVM guests (because it would improve performance on some functions by a great deal to avoid intercepting half a dozen IO operations to actually perform a single transaction - like one READ of the virtual hard-disk). I''d like to make sure that you''re aware that the AMD architecture also has a VMMCALL instruction, which is opcode (0F 01 D9). It would be great if you could implement some sort of auto-detect/switching so that your code works for AMD too. Of course, we could intercept invalid opcode and interpret the instruction, but that''s far from a practical solution, I would think. -- Mats> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Steve Ofsthun > Sent: 06 April 2006 22:10 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] [RFC] Hypercalls from HVM guests > > Hi, > > I am currently working on hypercalls from HVM guests. I > started with a set of Intel patches posted to xen-devel last > September. I currently have code running for both 32-bit and > 64-bit HVM guests running on a 64-bit hypervisor. > > I am curious why none of the original patches were accepted, > and what I might need to do to make them acceptable. > > Is other work being done in this area that hasn''t been submitted? > > Should I submit my version of the modified patches as is? > > The following list summarizes the changes. > > Hypervisor changes: > > o Add vmexit handling for the VMCALL instruction. This > includes adjustments > to hypercall arguments due to 32-bit vs. 64-bit calling > conventions. > > o Modify copy_to_user/copy_from_user to use hvm_copy for HVM guests. > > o Modify grant table setup to properly map the grant table > shared data for > hvm guests. > > o Provide alternate headers for compiling 32-bit HVM guest > code to interface > with a 64-bit hypervisor. Many of the hypervisor > structures used for > hypercalls vary between 32-bit and 64-bit guests. > > Dom 0 changes: > > o Modify HVM building to properly map in a xen start info > page and the shared > info page for event channel notifications. > > o Add a virtual PCI device to QEMU to facilitate event > channel handling. > > Dom U (HVM) driver changes: > > o Modify grant table setup for HVM guest code. > > o Modify event channel handling to interface with an > unmodified Linux kernel > running as an HVM guest. > > o Make misc xen support available as a loadable module. > > Steve > -- > Steve Ofsthun - Virtual Iron Software, Inc. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats wrote:> Interesting subject - I must have missed the September patchset... I''ve > been thinking a lot about para-virtualized drivers for HVM guests > (because it would improve performance on some functions by a great deal > to avoid intercepting half a dozen IO operations to actually perform a > single transaction - like one READ of the virtual hard-disk).This is exactly our interest as well.> I''d like to make sure that you''re aware that the AMD architecture also > has a VMMCALL instruction, which is opcode (0F 01 D9). It would be great > if you could implement some sort of auto-detect/switching so that your > code works for AMD too. Of course, we could intercept invalid opcode and > interpret the instruction, but that''s far from a practical solution, I > would think.Thanks for pointing that out. I didn''t realize the opcode was different. I should be able to easily alter the hypercall page initialization to use the proper AMD opcode. What is the preferred method to distinguish SVM vs. VMX from within guest code running in an HVM guest? Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Steve Ofsthun [mailto:sofsthun@virtualiron.com] > Sent: 07 April 2006 18:06 > To: Petersson, Mats > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests > > Petersson, Mats wrote: > > > Interesting subject - I must have missed the September patchset... > > I''ve been thinking a lot about para-virtualized drivers for > HVM guests > > (because it would improve performance on some functions by a great > > deal to avoid intercepting half a dozen IO operations to actually > > perform a single transaction - like one READ of the virtual > hard-disk). > > This is exactly our interest as well. > > > I''d like to make sure that you''re aware that the AMD > architecture also > > has a VMMCALL instruction, which is opcode (0F 01 D9). It would be > > great if you could implement some sort of auto-detect/switching so > > that your code works for AMD too. Of course, we could intercept > > invalid opcode and interpret the instruction, but that''s far from a > > practical solution, I would think. > > Thanks for pointing that out. I didn''t realize the opcode > was different. > I should be able to easily alter the hypercall page > initialization to use the proper AMD opcode.I think it''s got something to do with the two companies not talking about new opcodes with each other - probably in turn to do with not revealing what they are doing WITH those new opcodes. At least we have so far avoided having THE SAME opcode for different instructions ;-)> > What is the preferred method to distinguish SVM vs. VMX from > within guest code running in an HVM guest?Good question - the way I''d say is to look at CPUID to see if it''s "GeunineIntel" or "AuthenticAMD", but I''m not sure if that''s the BEST. Of course, this assumes the code is already aware that it''s in a HVM environment, which I''m not sure if you know that or not at the point you need to know if it''s AMD or Intel... Of course, if CPUID is intercepted, it may return other things (but it''s against the "rules" to lie about the brand of the CPU!) -- Mats> > Steve > -- > Steve Ofsthun - Virtual Iron Software, Inc. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7 Apr 2006, at 18:24, Petersson, Mats wrote:> Good question - the way I''d say is to look at CPUID to see if it''s > "GeunineIntel" or "AuthenticAMD", but I''m not sure if that''s the BEST. > Of course, this assumes the code is already aware that it''s in a HVM > environment, which I''m not sure if you know that or not at the point > you > need to know if it''s AMD or Intel... Of course, if CPUID is > intercepted, > it may return other things (but it''s against the "rules" to lie about > the brand of the CPU!)I like the idea of stealing some MSR space for this, and doing some initial interaction with the underlying hypervisor platform via RDMSR/WRMSR to known MSRs. We could ''read'' an ''MSR'' that would tell us the correct instruction sequence to do a hypercall (either directly, or maybe tell us a ''physical address'' to read the hypercall transport information from -- then we could have a hypercall transfer page just as we already do for paravirtualised guests). We just need to pick some MSRs that won''t get used by Intel or AMD in the future. There''s quite a lot of addressing space to carve up though. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: 07 April 2006 18:40 > To: Petersson, Mats > Cc: Steve Ofsthun; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests > > > On 7 Apr 2006, at 18:24, Petersson, Mats wrote: > > > Good question - the way I''d say is to look at CPUID to see if it''s > > "GeunineIntel" or "AuthenticAMD", but I''m not sure if > that''s the BEST. > > Of course, this assumes the code is already aware that it''s > in a HVM > > environment, which I''m not sure if you know that or not at > the point > > you need to know if it''s AMD or Intel... Of course, if CPUID is > > intercepted, it may return other things (but it''s against > the "rules" > > to lie about the brand of the CPU!) > > I like the idea of stealing some MSR space for this, and > doing some initial interaction with the underlying hypervisor > platform via RDMSR/WRMSR to known MSRs. We could ''read'' an > ''MSR'' that would tell us the correct instruction sequence to > do a hypercall (either directly, or maybe tell us a ''physical > address'' to read the hypercall transport information from -- > then we could have a hypercall transfer page just as we > already do for paravirtualised guests). > > We just need to pick some MSRs that won''t get used by Intel > or AMD in the future. There''s quite a lot of addressing space > to carve up though. > :-)I like this idea, it''s quirky and neat at the same time... But isn''t this going to be a catch-22 situation? We don''t know if we''re virtualized or not, so we can''t make hypercalls, and to find out, we read an unimplemented MSR, which on REAL hardware causes a GP fault (and probably also in SVM, since the map for SVM capturing MSR read/write operations is very specific - at least if we use a MSR like 0xb0000000 or such). Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would be better? As that''s defined to return all zero''s, and not cause any traps whatever value you use (unless the CPU is so old that it doesn''t support CPUID, of course). -- Mats> > -- Keir > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats wrote:>> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >> >> I like the idea of stealing some MSR space for this, and >> doing some initial interaction with the underlying hypervisor >> platform via RDMSR/WRMSR to known MSRs. We could ''read'' an >> ''MSR'' that would tell us the correct instruction sequence to >> do a hypercall (either directly, or maybe tell us a ''physical >> address'' to read the hypercall transport information from -- >> then we could have a hypercall transfer page just as we >> already do for paravirtualised guests). >> >> We just need to pick some MSRs that won''t get used by Intel >> or AMD in the future. There''s quite a lot of addressing space >> to carve up though. >> :-) > > I like this idea, it''s quirky and neat at the same time... > > But isn''t this going to be a catch-22 situation? We don''t know if we''re > virtualized or not, so we can''t make hypercalls, and to find out, we > read an unimplemented MSR, which on REAL hardware causes a GP fault (and > probably also in SVM, since the map for SVM capturing MSR read/write > operations is very specific - at least if we use a MSR like 0xb0000000 > or such).This sounds like a simple to use method for communicating with the HVM code, but I would like to gracefully detect native execution and print a useful error message at module load time. Recovering from a native mode exception will be very O/S specific (if allowed at all).> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would > be better? As that''s defined to return all zero''s, and not cause any > traps whatever value you use (unless the CPU is so old that it doesn''t > support CPUID, of course).This sounds encouraging, but is CPUID always trapped by the HVM code? Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steve Ofsthun wrote:> Petersson, Mats wrote: > > > This sounds like a simple to use method for communicating with the HVM > code, > but I would like to gracefully detect native execution and print a useful > error message at module load time. Recovering from a native mode > exception > will be very O/S specific (if allowed at all).PIO is probably a bit safer. PIO probing, while a bit ugly, is certainly frequently used. Plus, PIO instructions are not sensitive (whereas CPUID is) which means that it can also be used as a mechanism for non-HVM guests. Regards, Anthony Liguori>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would >> be better? As that''s defined to return all zero''s, and not cause any >> traps whatever value you use (unless the CPU is so old that it doesn''t >> support CPUID, of course). > > This sounds encouraging, but is CPUID always trapped by the HVM code? > > Steve_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7 Apr 2006, at 20:30, Steve Ofsthun wrote:>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) >> would >> be better? As that''s defined to return all zero''s, and not cause any >> traps whatever value you use (unless the CPU is so old that it doesn''t >> support CPUID, of course). > > This sounds encouraging, but is CPUID always trapped by the HVM code?It can be, and in practise yes it is so this could work. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:> On 7 Apr 2006, at 20:30, Steve Ofsthun wrote: > > >> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) > >> would > >> be better? As that''s defined to return all zero''s, and not cause any > >> traps whatever value you use (unless the CPU is so old that it doesn''t > >> support CPUID, of course). > > > > This sounds encouraging, but is CPUID always trapped by the HVM code? > > It can be, and in practise yes it is so this could work.CPUID doesn''t have any advantage over MSRs for this purpose because for custom CPUIDs like 0xb... you can''t use the normal "max count" mechanism of determining if a CPUID is supported. All that would work is to try it and handle the GPF if it didn''t work. That would give the same ugly implementation as with MSRs. Using the MSR would have the advantage of it being trappable in a para virtual kernel too. Or alternatively use some table in RAM/ROM space that can be searched for. That would allow to implement this simply in OS without having to change any exception handlers. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 8 Apr 2006, at 15:12, Andi Kleen wrote:>>> This sounds encouraging, but is CPUID always trapped by the HVM code? >> >> It can be, and in practise yes it is so this could work. > > CPUID doesn''t have any advantage over MSRs for this purpose because > for custom CPUIDs like 0xb... you can''t use the normal "max count" > mechanism > of determining if a CPUID is supported. All that would work is to try > it and handle the GPF if it didn''t work. That would give the same ugly > implementation as with MSRs.CPUID never faults. Well, unless the processor doesn''t support the instruction, but you find that out from EFLAGS.> Using the MSR would have the advantage of it being trappable in a para > virtual > kernel too.I would definitely prefer to use MSRs for gathering hypervisor signature and other information, but because of the possible hassle of catching faults I''d also support a signature return (and maybe identifying some hypervisor features) via a special CPUID index. The index could be greater than the normal "max count" and you''d determine if the index(es) were supported by checking for a well-known signature in EAX,EBX,ECX,EDX for the first of the hypervisor indexes. Running on native hardware would not fault and you''d expect it to be vastly unlikely that the final values of EAX thru EDX would coincidentally match a 128-bit signature. (Cue attempts to think up a 16-character signature string. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 7 Apr 2006, at 20:30, Steve Ofsthun wrote: > >>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) >>> would be better? As that''s defined to return all zero''s, and not >>> cause any traps whatever value you use (unless the CPU is so old >>> that it doesn''t support CPUID, of course). >> >> This sounds encouraging, but is CPUID always trapped by the HVM code? > > It can be, and in practise yes it is so this could work. > > -- Keir >If eax is set to a value outside the recognized range of CPUID currently defined, CPUID does not necessarily return all zero''s on Intel. It''s "Reserved" (Information returned for highest basic information leaf). Also "an unused index" can have conflicts in the future. If we just need to tell on which CPU the current HVM guest is running, I think "GeunineIntel" or "AuthenticAMD" is the best because it''s been used by native systems as well. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 Apr 2006, at 00:33, Nakajima, Jun wrote:> If eax is set to a value outside the recognized range of CPUID > currently > defined, CPUID does not necessarily return all zero''s on Intel. It''s > "Reserved" (Information returned for highest basic information leaf). > Also "an unused index" can have conflicts in the future. > > If we just need to tell on which CPU the current HVM guest is running, > I > think "GeunineIntel" or "AuthenticAMD" is the best because it''s been > used by native systems as well.Then how do you tell whether you are running on a hypervisor without executing some instruction that might fault? We would like to avoid requiring that. There is quite a lot of CPUID and MSR address space, and a random return value for CPUID when running natively is practically-speaking fine if we''re looking for a 128-bit signature. The only other option I think would be a BIOS table, probably below 1MB. I prefer the CPUID/MSR method. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 9 Apr 2006, at 00:33, Nakajima, Jun wrote: > >> If eax is set to a value outside the recognized range of CPUID >> currently defined, CPUID does not necessarily return all zero''s on >> Intel. It''s "Reserved" (Information returned for highest basic >> information leaf). Also "an unused index" can have conflicts in the >> future. >> >> If we just need to tell on which CPU the current HVM guest is >> running, I think "GeunineIntel" or "AuthenticAMD" is the best >> because it''s been used by native systems as well. > > Then how do you tell whether you are running on a hypervisor without > executing some instruction that might fault? We would like to avoid > requiring that.This is a different question, and I think detecting a virtual device (i.e. virtual block device, NIC) or chipset would be a cleaner way at this point. And that would be proper for the patch that Steve mentioned (we wrote it). The fact that it''s running on a hypervisor does not necessarily guarantee presence of such virtual devices (in fact they don''t exist today ;-). If we really need to tell if we are running on a hypervisor at a very early point or even in user-mode, I think CPUID with "an unused index" would be the simplest, but so far I haven''t seen any usage models that really require that. If we want to add virtualization hints for processor architectures (e.g. MMU) in guests, it would be needed.> > There is quite a lot of CPUID and MSR address space, and a random > return value for CPUID when running natively is practically-speaking > fine if we''re looking for a 128-bit signature.Many bits are already reserved for the future capabilities in CPUID, and MSR is CPU _model_ specific by definition, i.e. not architecturally clean. But my point is that we should specify "reserved for virtualization" or something in the H/W manual rather than inventing an ad hoc one (when we don''t really need). BTW, I think virtualization hints (nop on the native, hypercall on a hypervisor) would be very useful for performance optimizations.> > The only other option I think would be a BIOS table, probably below > 1MB. I prefer the CPUID/MSR method. > > -- KeirJun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 Apr 2006, at 14:56, Nakajima, Jun wrote:> This is a different question, and I think detecting a virtual device > (i.e. virtual block device, NIC) or chipset would be a cleaner way at > this point. And that would be proper for the patch that Steve mentioned > (we wrote it). The fact that it''s running on a hypervisor does not > necessarily guarantee presence of such virtual devices (in fact they > don''t exist today ;-). > > If we really need to tell if we are running on a hypervisor at a very > early point or even in user-mode, I think CPUID with "an unused index" > would be the simplest, but so far I haven''t seen any usage models that > really require that. If we want to add virtualization hints for > processor architectures (e.g. MMU) in guests, it would be needed.Executing hypercalls via an indirection page as we do for paravirtualised guests is an attractive idea. That would require more than just ''are we AMD or Intel'' and it would be nice to have that future-proofing level of indirection in the initial implementation. We could do that via the PCI device too (e.g., use a BAR) though that doesn''t seem so clean to me. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 9 Apr 2006, at 14:56, Nakajima, Jun wrote: > >> This is a different question, and I think detecting a virtual device >> (i.e. virtual block device, NIC) or chipset would be a cleaner way at >> this point. And that would be proper for the patch that Steve >> mentioned (we wrote it). The fact that it''s running on a hypervisor >> does not necessarily guarantee presence of such virtual devices (in >> fact they don''t exist today ;-). >> >> If we really need to tell if we are running on a hypervisor at a very >> early point or even in user-mode, I think CPUID with "an unused >> index" would be the simplest, but so far I haven''t seen any usage >> models that really require that. If we want to add virtualization >> hints for processor architectures (e.g. MMU) in guests, it would be >> needed. > > Executing hypercalls via an indirection page as we do for > paravirtualised guests is an attractive idea. That would require more > than just ''are we AMD or Intel'' and it would be nice to have that > future-proofing level of indirection in the initial implementation. We > could do that via the PCI device too (e.g., use a BAR) though that > doesn''t seem so clean to me. > > -- KeirYep. We should not use PCI device detection to detect such Xen-specific MMU features. And we should use PCI device detection to detect a virtual device because the guest needs to initialize and set up the plumbing (e.g. interrupt lines) as a device. I think such an initial implementation for Xen MMU can use CPUID (with whatever index), and I think we can come back with a specific value for the index when a patch is ready. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stephen C. Tweedie
2006-Apr-12 15:39 UTC
Re: [Xen-devel] Re: [RFC] Hypercalls from HVM guests
Hi, On Sat, 2006-04-08 at 16:05 +0100, Keir Fraser wrote:> CPUID never faults. Well, unless the processor doesn''t support the > instruction, but you find that out from EFLAGS.What does vmx_vmexit_do_cpuid() do then? I doubt there are many VMX-capable CPUs without cpuid(). :-) --Stephen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, On Sun, 2006-04-09 at 06:56 -0700, Nakajima, Jun wrote:> If we really need to tell if we are running on a hypervisor at a very > early point or even in user-mode, I think CPUID with "an unused index" > would be the simplest, but so far I haven''t seen any usage models that > really require that. If we want to add virtualization hints for > processor architectures (e.g. MMU) in guests, it would be needed.If you want it for MMU setup right at the earliest stages, prior to entering 32-bit mode, you can probably already get this today by searching for "HVMAssist" in the rombios, and the same information is visible from 32-bit supervisor mode (but not from user space unless the OS decides to export it.) --Stephen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 Apr 2006, at 16:39, Stephen C. Tweedie wrote:> >> CPUID never faults. Well, unless the processor doesn''t support the >> instruction, but you find that out from EFLAGS. > > What does vmx_vmexit_do_cpuid() do then? I doubt there are many > VMX-capable CPUs without cpuid(). :-)Yes, you can make cpuid trap to the hypervisor if running an hvm guest. But that''s quite different from a guest-visible trap or fault. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-Apr-13 12:53 UTC
RE: [Xen-devel] Re: [RFC] Hypercalls from HVM guests
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Keir Fraser > Sent: 12 April 2006 18:06 > To: Stephen C. Tweedie > Cc: sofsthun@virtualiron.com; xen-devel@lists.xensource.com; > Andi Kleen > Subject: Re: [Xen-devel] Re: [RFC] Hypercalls from HVM guests > > > On 12 Apr 2006, at 16:39, Stephen C. Tweedie wrote: > > > > >> CPUID never faults. Well, unless the processor doesn''t support the > >> instruction, but you find that out from EFLAGS. > > > > What does vmx_vmexit_do_cpuid() do then? I doubt there are many > > VMX-capable CPUs without cpuid(). :-) > > Yes, you can make cpuid trap to the hypervisor if running an > hvm guest. > But that''s quite different from a guest-visible trap or fault.Not only is is POSSIBLE to intercept (note that INTERCEPT and FAULT are two different things, as Keir explained), but it''s necessary to correctly emulate certain environmental things... For example, if we have a 32-bit Hypervisor running on a Athlon64 processor, we don''t want the CPUID instruction return support for 64-bit mode - although it''s correct that the PROCESSOR supports 64-bit mode, the Hypervisor wouldn''t really be able to cope with this mode - so having a Linux install say "Are you sure you want to install a 32-bit OS on this 64-bit processor" (or worse, automatically select the "better" 64-bit option on it''s own), wouldn''t really be what we want... Similarly, PAE-support in the hypervisor should be present, or we shouldn''t allow the guest to see that the processor supports PAE. Multiprocessor identification in CPUID would be another case where we want to lie about what''s really there and what the guest sees. But as for the SVM implementation (I haven''t looked at the VMX version lately), there''s no injection of exceptions in the svm_vmexit_do_cpuid(), and the CPUID instruction itself is not one that CAN FAULT, unless we''re talking about ancient CPU''s. -- Mats> > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel