[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/2] x86/monitor: Add new monitor event to catch all vmexits
- To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 27 Apr 2022 11:22:17 +0200
- 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RnlJQZcjgUTUpsRsT1TXqVmTTBHXsxQJSZtrXBDpBrU=; b=f81erv32yU29M04QCFWC/vu4WcXyYVuu9MpNFBwLb2JSgbukiDrWQn3F7P/QQ26otxSW15MrbRW9JorYOuH1ppQMa8igqXNpPvCdBvB1724m6cueq02BxCa/v3I8zBd3uvcvRf+OYwHzlv2Pvgy1pdL0RiLysOnYyPwy30fDaiL5HRGp1e3At2V06yX6w3/lWDcY11nFMqU83TjwJVEI/rcqrckTnrxOUWZlu7Jh5sBPmhaIvppvyG1gk+idssYQdNbQkk8AJ0YQRp1JqSwQddt8anMHzVy0eMgc/ZkJKfE6CpEt4p6jRpZ/viRARQmw3o0vXhFL0f0t63Bmjt6nxw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8nwkKQV9RMjXKUEpj5KmJJLjj2X7QNYxSxzgJ1qKhb/KPafP2fXkJ6qaRMkdKFoHSpwndxDAECGziYGoahXPG7yI0CoeILWi5ZCsqVx2xy0dDZpFcEB9RU9HLfy8yYs72BhPA3zINqdr/qHSxn43nhD6vO7QlHpGvYPmegqso2q0Jb+779/+d9QlE8ZY6iW2wcFibWYydSNSWkpwF7jqwr0m3jShnJbQHSTKoUTVOjTtsDF/c22PCSODM9dMOEe5476QW/ygte63HqLcGGrk+aC6eRvqGelkKW1pkNd5v0eL6ujZi6+3zR7FZKfXfJ0wC9/zbQBZHW6KrWkKvzoIw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
- Delivery-date: Wed, 27 Apr 2022 09:22:30 +0000
- Ironport-data: A9a23:y9oIpKnF8YGL/6MRS5QGbJno5gw/J0RdPkR7XQ2eYbSJt1+Wr1Gzt xIZX2CHP6qDN2Pxf4xya4y19k0Ov8TRmNVjTFdp+30zHiMWpZLJC+rCIxarNUt+DCFioGGLT Sk6QoOdRCzhZiaE/n9BCpC48T8kk/vgqoPUUIYoAAgoLeNfYHpn2EoLd9IR2NYy24DlWV3V4 rsenuWEULOb828sWo4rw/rrRCNH5JwebxtB4zTSzdgS1LPvvyF94KA3fMldHFOhKmVgJcaoR v6r8V2M1jixEyHBqD+Suu2TnkUiGtY+NOUV45Zcc/DKbhNq/kTe3kunXRa1hIg+ZzihxrhMJ NtxWZOYSyIMIaDUs9Yma0N2T3B8IrQXxYb6GC3q2SCT5xWun3rE5dxLVRlzGLJCv+F9DCdJ6 OASLy0LYlabneWqzbmnS+5qwMM+MM3sO4BZsXZlpd3bJa9+HdafHOOXuJkBhGZYasNmRJ4yY +IDbjVidlLYagBnMVYLEpMu2uyvgxETdhUG+Q7P/vJouQA/yiRP3bbwPvXbdeewTOFvwxekl EjP2m7QV0Ry2Nu3jGDtHmiXrvPGmCrgcJ4RELC++e9nhBuYwWl7IAEfUFKg5/20jEGvVtZ3K koI9y5opq83nGS7Q9+4UxCmrXqsuh8HR8EWA+A88BuKyKff/0CeHGdsZiFFQMwrsokxXzNC/ l2GhdTyHhR0raaYD3ma89+8rzm/JCwUJm8qfjIfQE0O5NyLiIMuihPCSP5zHajzicf6cRnr2 CyDpiU6g7QVjOYI2r+98FSBhCijzrDATxU85wHedmik8g90aoOja4Gyr1Pc6J5oNJ6YVFKIu HEOhuCU7fwCAJ+AkiCAWqMGG7TBz/SYNnvaiF1mHZgk/hys/WKuecZb5zQWDERkLMcCPyPoa Un7uAVN6ZsVN3yvBZKbeKq0AsUuiK3/T9LsU6mMasIUO8AgMgia4CtpeEicmXj3l1Qhmr0+P pHddtuwCXEdCuJsyz/eq/oh7ILHDxsWnQv7La0XBTz+uVZCTBZ5kYs4DWY=
- Ironport-hdrordr: A9a23:Z9wKSa297hoFJHJjDL2v+wqjBTtyeYIsimQD101hICG9Lfb0qy n+pp4mPEHP4wr5OEtOpTlPAtjkfZr5z+8M3WB3B8bYYOCGghrQEGgG1+ffKlLbexEWmtQttp uINpIOcuEYbmIK8voSgjPIdOrIqePvmM7IuQ6d9QYKcegDUdAd0+4TMHf+LqQZfnglOXJvf6 Dsm/av6gDQMUj+Ka+Adwo4dtmGg+eOuIPtYBYACRJiwA6SjQmw4Lq/NxSDxB8RXx5G3L9nqA H+4kbEz5Tml8v+5g7X1mfV4ZgTsNz9yuFbDMjJrsQOMD3jhiuheYwkcbyfuzIepv2p9T8R4Z LxiiZlG/42x2Laf2mzrxeo8w780Aw243un8lOciWuLm72PeBsKT+56wa5JeBrQ7EQt+Ptm1r hQ4m6fv51LSTvdgSXU/bHzJl9Xv3vxhUBnvf8YjnRZX4dbQqRWt5Yj8ERcF4pFND7m6bogDP JlAKjnlblrmGuhHjDkV1RUsZ+RtixZJGbFfqFCgL3Y79FupgE586NCr/Zv20vp9/oGOu15Dq r/Q+BVfYp1P74rhJJGdZk8qPSMexzwqDL3QRSvyAfcZeg600ykke+E3JwFoMeXRbcv8Lwe3L z8bXIwjx9GR6upM7zC4KF2
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Apr 26, 2022 at 02:53:54PM -0400, Tamas K Lengyel wrote:
> On Tue, Apr 26, 2022 at 4:50 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >
> > On Mon, Apr 25, 2022 at 11:40:11AM -0400, Tamas K Lengyel wrote:
> > > On Mon, Apr 25, 2022 at 10:41 AM Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > wrote:
> > > >
> > > > On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote:
> > > > > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> > > > > index 3079726a8b..30ca71432c 100644
> > > > > --- a/xen/arch/x86/monitor.c
> > > > > +++ b/xen/arch/x86/monitor.c
> > > > > @@ -332,6 +332,20 @@ int arch_monitor_domctl_event(struct domain *d,
> > > > > break;
> > > > > }
> > > > >
> > > > > + case XEN_DOMCTL_MONITOR_EVENT_VMEXIT:
> > > > > + {
> > > > > + bool old_status = ad->monitor.vmexit_enabled;
> > > > > +
> > > > > + if ( unlikely(old_status == requested_status) )
> > > > > + return -EEXIST;
> > > >
> > > > What about if the requested status is the same as the current one, but
> > > > vmexit sync is not?
> > >
> > > You need to clear the currently registered event first, then register
> > > the new one.
> > >
> > > > IOW, I'm not sure this check is helpful, and you could likely avoid
> > > > the old_status local variable.
> > >
> > > It is helpful on the callee side. Usually the callee needs to keep
> > > track of the state of what events are enabled so that it can clean up
> > > after itself and if it ever runs into trying to set the event to
> > > something it's already set to then that indicates its state being
> > > out-of-sync.
> >
> > Hm, right. I wonder if you should also check that the ring is empty
> > before changing the status? So that the callee doesn't change the
> > status while requests are still pending on the ring from the previous
> > type?
>
> No, that becomes tricky because really the only way to ensure the ring
> remains empty from the userspace is to pause the domain, which is very
> heavy handed. There is nothing wrong with asking Xen not to produce
> more of a certain type of request while still being able to handle the
> ones that are already on the ring. For setups where the two should
> happen at the same time is where the toolstack first pauses the
> domain, clears the ring, then disables the event. Both are valid
> approaches.
OK, so we rely on the callee to drain the ring properly when wanting
to change VMEXIT events.
Thanks, Roger.
|