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

Re: [Xen-devel] [PATCH V6] x86/altp2m: Hypercall to set altp2m view visibility

  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Isaila Alexandru <aisaila@xxxxxxxxxxxxxxx>
  • Date: Tue, 24 Mar 2020 12:46:12 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.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=kWPhZ2Bv2928HxcsIiPik3lPDAsXQQfiQbAxBZpxp0s=; b=EBbjLd7N4iIviB/yXxA7pumRntsOFUl9Tdw8IhLUhqVXPUrukOW/+1AyomrC4YPyl5SEmHnc7i0tib5llPv9ZGlBNsQceeQmmc/xgvoS7bKoqJqI9u+KBdpOgxeCzsgfMtejqbShOenWISx8VoweWUU9DYgStN8Ub9aw0kPNQBZBsr51pO7hVcHs/Fc8KBq3it6CrsJs4cJDOiQ+QE3V6yg8gWAtME1iJdno03artpnVSseuWoeNOpOqQc5dSm/P4PIt6GQFeH1K8L9WrdqowarvAEGvxSChqROT3HTuVmOc7dOef7iNQ9Vkl4uxPF/rIMG+FgP75xPQFf5abV2vPw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BSTCjliUY94k3SWyeN5kZYVXJmLjYDar/ZSsr+2/txH1xzH8LHmA3+1LqVmczjYblaGP+2O5NsTJiJ6yqgmENuI4ot9Y9YzWyLBKA6+f20ZmhcHBSZDn5dqObxcwkRjSCopmxe7VYBSw7Cn51B4GVQ4VpmDzFWBHTD5q2JyhGPJkLS64n6zDCJjRaeZbWy3BsW271bPis4df1toKzSsOkI2XWqewbOLr0z9VbjiAcbQcWOl9UXbpuEpCr4j/WYJUdkEheoqhXAKU1Gl3KEr5qghBECgvHQbCdJWzLsdNkWbVKlYTZWe9zI7giYXHSfJlA/OG8J/trNqRgSC6rwNHxA==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=aisaila@xxxxxxxxxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 24 Mar 2020 10:46:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Kevin and sorry for the long reply time,

On 10.03.2020 04:04,  sTian, Kevin wrote:
From: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>
Sent: Tuesday, March 3, 2020 8:23 PM

At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.

I look forward to more elaboration of the motivation, especially for one
who doesn't track altp2m closely like me. For example, do_altp2m_op
mentions three modes: external, internal, coordinated. Then is this patch
trying to limit the view switch in all three modes or just one of them?
from the definition clearly external disallows guest to change any view
(then why do we want per-view visibility control) while the latter two
both allows guest to switch the view. later you noted some exception
with mixed (internal) mode. then is this restriction pushed just for
limited (coordinated) mode?

As you stated, there are some exceptions with mixed (internal) mode.
This restriction is clearly used for coordinated mode but it also restricts view switching in the external mode as well. I had a good example to start with, let's say we have one external agent in dom0 that uses view1 and view2 and the logic requires the switch between the views. At this point VMFUNC is available to the guest so with a simple asm code it can witch to view 0. At this time the external agent is not aware that the view has switched and further more view0 was not supposed to be in the main logic so it crashes. This example can be extended to any number of views. I hope it can paint a more clear picture of what this patch is trying to achive.

btw I'm not sure why altp2m invents two names per mode, and their
mapping looks a bit weird. e.g. isn't 'coordinated' mode sound more
like 'mixed' mode?

Yes that is true, it si a bit weird.

The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.

if one doesn't want to make view visible to vmfunc, why can't he just
avoids registering the view at the first place? Are you aiming for a
scenario that dom0 may register 10 views, with 5 views visible to
vmfunc with the other 5 views switched by dom0 itself?

That is one scenario, another can be that dom0 has a number of views created and in some time it wants to be sure that only some of the views can be switched, saving the rest and making them visible when the time is right. Sure the example given up is another example.




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