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

Re: [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED

  • To: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 22 Feb 2021 12:08:45 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZvQYY4KOH8lL75WEUmYjowiYS7ZA9LVTkSG5qn0uycA=; b=L2hBo5Pqf/1ywuOhWwAEZTFh44BAH/PFfDzuG5ZrISP9o59XxY3SRkfa9cSmeLjW3JnP7EUQQUOMpiB8mH/ai20YThiTZLRRjug76Wsqn56qJjbdUpXjOFUQWTy4Z34Se4C2Iz3VMAMk5VCy61mu2Yi9lB83KxlbNtD1ssjT/naK9rclkiFmRsOHvEe2ecjSmuJB1msi7goIwJ/gQq9Il10RywzQEyTboZXpDW4dq5BXXJTPV3+CcGegsdncKssNgR6OPZrtpMtUQBEDJ7Dks8QUtpruj0+48gOS0bgwi/k+bNSSOClU6v0XB8fSGr3RwTVjuqycuKiZZUiclXcwnw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xr8HfZrXvrJ9UaTwrD6xVMcu5KTgnbQrpEfXGo8x1/6G1o2nXJi+P7Wdu7xcQ4/gyXGNQbAryEAygTrTBBzyEzcOE+jLa8TvBTNRgtXGrExXyQGPsPIzp+xTc8XkxXENRC0SRgbGSl4blPtL5U+IJbyR0FDCXDypIJs1q/xegDnZ64Ho4IIRJDMLuRGBcOfYzH9ew9RBOyr7WcnZQrK4I8Q1htIuDiFYG00xzlLLPG9aImsFmQBPjE1qYgjHb4o+XmGXwFwkAat5L/IkWjzO2m+9xpi6Tz4z9oXwiAgUhSkPuCDdws/cguLll9/ovzlDz2QC6OJmqdd/hXTKGTQBOg==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <iwj@xxxxxxxxxxxxxx>, <wl@xxxxxxx>, <anthony.perard@xxxxxxxxxx>, <jbeulich@xxxxxxxx>, <andrew.cooper3@xxxxxxxxxx>, <jun.nakajima@xxxxxxxxx>, <kevin.tian@xxxxxxxxx>
  • Delivery-date: Mon, 22 Feb 2021 11:09:19 +0000
  • Ironport-sdr: CuUk7IhEUHwL+qJqZxmF4N5PFOn5+rkvzAysosndqZC5gkk+Fa5BoBSvoaEzZZWhZ5SDfBr34w 1G9DX5L2wThCHFZgwNYx0dI1oDg1oznjt8z3GKwfgLWoJIAct3lt4TR6xpwllGgMgD2XbXOdgW /VI9gRL9DMygviE4jIE6/LZY+puDHx+L/lMKCVVX85skeVww+7QXr6kM8rKRCTW7J+R5Ksbn7M zj2ZkF0AF2XoJUWzIeMa2fxG9vt44qTbd4yOGIiiCroG1RVpibqecBYaCUEfkqM/Y5FbvUFo0u pO4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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?

But having such a list of ignored MSRs in msr_policy makes the whole
get/set logic a bit weird, as the user would have to provide a buffer
in order to get the list of ignored MSRs.

> > Isn't is possible to convey this data in the xl migration stream
> > instead of having to pack it with MSRs?
> I haven't looked at this but again --- the feature itself has nothing to do 
> with migration. The fact that folding it into policy makes migration of this 
> information "just work" is just a nice side benefit of this implementation.

IMO it feels slightly weird that we have to use a MSR (MSR_UNHANDLED)
to store this option, seems like wasting an MSR index when there's
really no need for it to be stored in an MSR, as we don't expose it to

It would seem more natural for such option to live in arch_domain as a
rangeset for example.

Maybe introduce a new DOMCTL to set it?

#define XEN_DOMCTL_msr_set_ignore ...
struct xen_domctl_msr_set_ignore {
    uint32_t index;
    uint32_t size;

Thanks, Roger.



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