[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC - Minutes




> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: Tuesday, August 21, 2018 11:58 PM
> To: Jan Beulich; Zhang, Yu C
> Cc: davorin.mista@xxxxxxxxxx; mirela.simonovic@xxxxxxxxxx; Brian Woods;
> JanakarajanNatarajan; Julien Grall; Matt Spencer; robin.randhawa@xxxxxxx;
> Lars Kurth; Paul Durrant; Roger Pau Monne; Sergey Dyasli; vfachin@xxxxxxx-
> jv.com; Jarvis Roach; Stewart Hildebrand; Artem Mygaiev; Volodymyr
> Babchuk; Christopher Clark; Rich Persaud; tamas.k.lengyel@xxxxxxxxx; intel-
> xen; Ji, John; Stefano Stabellini; xen-devel; anastassios.nanos@xxxxxxxxx;
> Daniel Kiper; Juergen Gross; committers@xxxxxxxxxxxxxx;
> edgar.iglesias@xxxxxxxxxx
> Subject: Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC
> - Minutes
> 
> On 21/08/2018 16:51, Jan Beulich wrote:
> >>>> On 21.08.18 at 17:28, <yu.c.zhang@xxxxxxxxx> wrote:
> >> Thanks Lars for the summary, and sorry for the late update.
> >>
> >> My question is about the cpuid policy for MAXPHYSADDR in Xen.
> >>
> >> It seems Xen is exposing the host MAXPHYSADDR value to HVM as the
> default
> >> choice. And I am wondering, what if a VM is created on a hardware
> platform
> >> with address width A, and later migrated to another platform with
> address
> >> width B? Should this be allowed in Xen?
> > Andrew's further leveling work is, afaiu, going to include leveling of
> > that field as well.
> 
> I certainly planned to, but as it turns out, that it is rather more
> complicated than I'd hoped.
> 
> There is a corner case where, if maxphyaddr is levelled lower than the
> current hardware, and the guest is relying on #PF[RSVD] tricks, if the
> only reserved bit(s) they set were in the difference between the real
> and virtualised maxphyaddr, and the pagewalk takes an access violation
> rather than a terminal fault, Xen has no way of faking up the RSVD
> property because the access won't elicit an EPT-based VMExit.
> 

Thanks Andrew, this is the trivial problem that I have been worrying. On ICX,
I do not want a  5 level EPT as the default choice, and I will have to expose
a smaller address width to the guest. And even without 5 level EPT, we still
would like to have a smaller address width in VM for the sake of migration...

B.R.
Yu

> Given that migration has been working well enough thus far (with the
> CPUID view of maxphyaddr changing under the guests feet), this may be of
> little concern, but it still has me somewhat worried.
> 
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.