[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains
>>> On 23.01.18 at 10:24, <jgross@xxxxxxxx> wrote: > On 23/01/18 09:53, Jan Beulich wrote: >>>>> On 23.01.18 at 07:34, <jgross@xxxxxxxx> wrote: >>> On 22/01/18 19:39, Andrew Cooper wrote: >>>> One of my concerns is that this patch series moves further away from the >>>> secondary goal of my KAISER series, which was to have the IDT and GDT >>>> mapped at the same linear addresses on every CPU so a) SIDT/SGDT don't >>>> leak which CPU you're currently scheduled on into PV guests and b) the >>>> context switch code can drop a load of its slow instructions like LGDT >>>> and the VMWRITEs to update the VMCS. >>> >>> The GDT address of a PV vcpu is depending on vcpu_id only. I don't >>> see why the IDT can't be mapped to the same address on each cpu with >>> my approach. >> >> You're not introducing a per-CPU range in the page tables afaics >> (again from overview and titles only), yet with the IDT needing >> to be per-CPU you'd also need a per-CPU range to map it to if >> you want to avoid the LIDT as well as exposing what CPU you're >> on (same goes for the GDT and the respective avoidance of LGDT >> afaict). > > After a quick look I don't see why a Meltdown mitigation can't use > the same IDT for all cpus: the only reason I could find for having > per-cpu IDTs seems to be in SVM code, so it seems to be AMD specific. > And AMD won't need XPTI at all. Isn't your RFC series allowing XPTI to be enabled even on AMD? > The GDT of pv domains is already in the per-domain region even without > my patches, so I don't have to change anything regarding usage of LGDT. Andrew's point was that eliminating the LGDT is a secondary goal. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |