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

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 23 Feb 2021 10:34:25 +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=ylQB6UdonLTXrzMiypbu+eZrZZWQq2NInzj2fKjWhaw=; b=ZuOMi75qzDGu+nVPTJma//E8+UVmgLG/T/hMsaz+SbZ7sh25PfP4rQRSAu3ZPhT7OlxXALYvGbaGdj8KxaNlu9Zy2SddbbscozCrXqeN0efdzNBRNfM2ZDjPM4tMEmp3ikuAUJ8HI3IxVWF0qcp1x+o3pdVycSPkqM8QT9gABOax8U7yN6lZUpN5JhYCmgehe68OolB6UuTvMEoJauZbxp6JktNjWVd9xNJoehNngNTFQLLKr5oUoa40TkCGtTXmdAyMeZx3XzKJ7KhiECRMMzoH4IqZc/iDB+KgxW9PTxjzk5mQH6XjxpGAW/p3cWhCqO4fr4HX65aJlNkvyt4r7g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eZcVOjLibKuqskGHYwceMldM9ELA9RVocPjMj8Txzq4acUDcvFhB+CFvWAHV/4CR5afbSouqjOP08FP5qRyk+FPA4HTSwGIifH9tUPaeX+MwTXXuLChRY7XEl1jItgUcjLnKZi0X035GYpOfnQjmdIkjYmGuYbKyW8j5Jc+KvjTYWAFIY5RuzSa/HB7FNG2ixlajnd0eiLgGFunhXaFFTh5reQ012R1YGi0z6GNF2ejk4YVCsrpMD9YEqmNxpmg1xtds2qbywfIFf1Zr7LJw8kKB8NAmgqm6daxDr8EHzjibUgGYcVBPWkLPUJaQ3rS9oaB9b92zy1LzI129FA/YkA==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <iwj@xxxxxxxxxxxxxx>, <wl@xxxxxxx>, <anthony.perard@xxxxxxxxxx>, <andrew.cooper3@xxxxxxxxxx>, <jun.nakajima@xxxxxxxxx>, <kevin.tian@xxxxxxxxx>
  • Delivery-date: Tue, 23 Feb 2021 09:34:41 +0000
  • Ironport-sdr: 3IGz5ZaZZzreJYT8gcBgo0KqgcsOggKGYJVPHI8BJ63nMU+Bup50SVrf/T2PGg4SMMSn4FNQpV NNIFztnTp/r5nU0DYVJIGg5Td/TUUp8byvExfZ+Z30Pvf+Wr3RGgdMxqcStIy2AIWGjFBfqIRv aP/SqKPAHr3lSatL6qYoECsl1jKoO5jW5bsp+vFaUCtDHuwu6in+qm+0dw0uGaUXLFnahvYqeU NeJiur5gXNdvKPAwKwRwLIHLix3xoABMnbU+SdKWQ0466oCdZ3eeYlaIt6y31pg8KaIJukwZ/P isY=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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

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.




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