Re: [Xen-devel] [PATCH v3 2/4] x86/compat: Test both PV and PVH guests for compat mode

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.07.15 at 00:20, <boris.ostrovsky@xxxxxxxxxx> wrote:
> Add is_pvh_32bit_domain() macro and use it alongside is_pv_32bit_domain() 
> where necessary.
> 
> Since PVH guests cannot change execution mode, has_32bit_shinfo is a good
> indicator of whether the guest is PVH and 32-bit.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

Relative to what is in the tree right now this is fine, but ...

> @@ -771,7 +771,7 @@ int arch_set_info_guest(
>  
>      /* The context is a compat-mode one if the target domain is compat-mode;
>       * we expect the tools to DTRT even in compat-mode callers. */
> -    compat = is_pv_32bit_domain(d);
> +    compat = is_pv_32bit_domain(d) || is_pvh_32bit_domain(d);

... won't this and ...

> @@ -1203,7 +1204,7 @@ void arch_get_info_guest(struct vcpu *v, 
> vcpu_guest_context_u c)
>  {
>      unsigned int i;
>      const struct domain *d = v->domain;
> -    bool_t compat = is_pv_32bit_domain(d);
> +    bool_t compat = is_pv_32bit_domain(d) || is_pvh_32bit_domain(d);

... this get in the way of what we called "no-pm" on yesterday's call?
I would assume that for the transitional period both ought to be able
to co-exist.

Plus - is this in line with what the tools are doing? Aren't they
assuming !PV <=> native format context? I.e. don't you need
to treat differently v->domain == current->domain and its
opposite? Roger btw. raised a similar question on IRC earlier
today...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel