Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Jan
> Beulich
> Sent: 27 September 2017 15:42
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV
> domain to map guest mfns
> 
> >>> On 27.09.17 at 16:22, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 27 September 2017 14:31
> >> >>> On 27.09.17 at 14:49, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> > Ok, I'll claim the final cmd value then.
> >>
> >> Final? We've got 5 left (for a total of 3 bits) afaict.
> >
> > Really? Maybe I misread... looks like only 2 bits to me.
> 
> Maybe you and I looked in different places. I'm deriving this from
> 
>         cmd = req.ptr & (sizeof(l1_pgentry_t)-1);
> 
>         switch ( cmd )
> 
> in do_mmu_update(). Only 32-bit non-PAE guests would have been
> limited to 2 bits.

Ah, ok. I was going off what it says in the header, where the comments state 
that [0:1] are command bits and [:2] are address bits, but for 64-bit or PAE 
guests then it makes sense that bit 2 is up for grabs. Anyway I can use 3, 
which still fits in bits [0:1].

  Paul 

> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel