[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XSA-60 solutions
>>> On 07.10.13 at 18:03, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote: > Jan Beulich wrote: >>>>> On 07.10.13 at 16:29, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> >>>>> wrote: Any comments/suggestions? >> >> As pointed out in earlier private conversation, I think that the dual >> table approach would be preferable if it can be made work. > > No, solution 2 has an important update compared with our private > conversation before: > The old solution 2 is, Xen do nothing for guest cr0.cd setting. > The new solution 2 in this email is, Xen set IA32_PAT fields as UC when > needed (that means, only when guest work with vt-d but vt-d non-snooped, > since > under this case h/w can not guarantee cache coherency), so that all guest > memory type are UC. For other cases (when guest work w/o vt-d, and when guest > work with vt-d but vt-d snooped), Xen can still do nothing for guest cr0.cd > setting (since h/w has guaranteed cache coherency, otherwise Xen doesn't dare > to do what it does now -- it set iPAT bit as 1, totally ignoring guest memory > type point of view). > > Compared with Dual-EPT solution, it's much simpler (only need IA32_PAT MSR > emulation under rare case) and avoid the inconsistency issue between 2 EPT > tables. Right - as long as PAT is guaranteed to only be used for guest induced memory accesses, that sounds like a viable yet not too intrusive solution. Short of anyone else having an opinion here, why don't you start drafting a patch for this? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |