[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED
On Tue, Feb 23, 2021 at 08:57:00AM +0100, Jan Beulich wrote: > On 22.02.2021 22:19, Boris Ostrovsky wrote: > > > > On 2/22/21 6:08 AM, Roger Pau Monné wrote: > >> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote: > >>> On 2/18/21 5:51 AM, Roger Pau Monné wrote: > >>>> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote: > >>>>> When toolstack updates MSR policy, this MSR offset (which is the last > >>>>> index in the hypervisor MSR range) is used to indicate hypervisor > >>>>> behavior when guest accesses an MSR which is not explicitly emulated. > >>>> It's kind of weird to use an MSR to store this. I assume this is done > >>>> for migration reasons? > >>> > >>> Not really. It just seemed to me that MSR policy is the logical place to > >>> do that. Because it *is* a policy of how to deal with such accesses, > >>> isn't it? > >> I agree that using the msr_policy seems like the most suitable place > >> to convey this information between the toolstack and Xen. I wonder if > >> it would be fine to have fields in msr_policy that don't directly > >> translate into an MSR value? > > > > > > We have xen_msr_entry_t.flags that we can use when passing policy array > > back and forth. Then we can ignore xen_msr_entry_t.idx for that entry > > (although in earlier version of this series Jan preferred to use idx and > > leave flags alone). > > Which, just to clarify, was not the least because of the flags > field being per-entry, i.e. per MSR, while here we want a global > indicator. We could exploit a bit the xen_msr_entry_t structure and use it like: typedef struct xen_msr_entry { uint32_t idx; #define XEN_MSR_IGNORE (1u << 0) uint32_t flags; uint64_t val; } xen_msr_entry_t; Then use the idx and val fields to signal the start and size of the range to ignore accesses to when XEN_MSR_IGNORE is set in the flags field? xen_msr_entry_t = { .idx = 0, .val = 0xffffffff, .flags = XEN_MSR_IGNORE, }; Would be equivalent to ignoring accesses to the whole MSR range. This would allow selectively selecting which MSRs to ignore, while not wasting a MSR itself to convey the information? It would still need to be stored somewhere in the Xen internal domain structure using a rangeset I think, which could be translated back and forth into this xen_msr_entry_t format. Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |