[RFC] Hypercalls from HVM guests

[RFC] Hypercalls from HVM guests

[Steve Ofsthun]

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.

RE: [RFC] Hypercalls from HVM guests

[Yu, Ke]

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

RE: [RFC] Hypercalls from HVM guests

[Petersson, Mats]

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

Re: [RFC] Hypercalls from HVM guests

[Steve Ofsthun]

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.

RE: [RFC] Hypercalls from HVM guests

[Petersson, Mats]

 

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

Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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

RE: [RFC] Hypercalls from HVM guests

[Petersson, Mats]

 

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

Re: [RFC] Hypercalls from HVM guests

[Steve Ofsthun]

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.

Re: [RFC] Hypercalls from HVM guests

[Anthony Liguori]

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

Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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

Re: [RFC] Hypercalls from HVM guests

[Andi Kleen]

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

Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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

RE: [RFC] Hypercalls from HVM guests

[Nakajima, Jun]

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

Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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

RE: [RFC] Hypercalls from HVM guests

[Nakajima, Jun]

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.
> 
>   -- Keir

Jun
---
Intel Open Source Technology Center

Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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

RE: [RFC] Hypercalls from HVM guests

[Nakajima, Jun]

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.
> 
>   -- Keir

Yep. 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

Re: Re: [RFC] Hypercalls from HVM guests

[Stephen C. Tweedie]

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

RE: [RFC] Hypercalls from HVM guests

[Stephen C. Tweedie]

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

Re: Re: [RFC] Hypercalls from HVM guests

[Keir Fraser]

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