[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |