|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for H
On 15/1/07 8:31 am, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> An HVM guest does not use DOMF_COMPAT. You can deduce its
>> execution mode
>> from CS attribute bytes. And of course it can switch execution mode
>> back and
>> forth as it runs, and on different VCPUs, etc.
>
> So what's the proposed way to reuse compat code for HVM guest?
> Extend IS_COMPAT() to cover HVM domain even when
> DOMF_COMPAT is not set, or invoke compatible layer directly when
> required. In any case, I just didn't see why IS_COMPAT() branch is
> placed under is_hvm_vcpu for now. :-)
Hmmm there is underlying code shared by both compat and native hypercall
layer that will check IS_COMPAT. So jumping at the compat layer is
insufficient (even though that is precisely what the hvm hypercall wrapper
does).
Basically this work isn't complete yet. Probably what will happen is that
the IS_COMPAT() test will be made per-vcpu rather than per-domain and we
will set the per-vcpu flag correctly for an hvm guest at least whenever it
vmexits for a hypercall. Or we will make IS_COMPAT() look at shadow-mode
guest_levels if it is invoked on an HVM vcpu.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|