From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Catterall Subject: Re: RFC on deprivileged x86 hypervisor device models Date: Mon, 20 Jul 2015 15:10:41 +0100 Message-ID: <55AD0161.3050708@citrix.com> References: <55A8D477.2060909@citrix.com> <55A92B530200007800092802@mail.emea.novell.com> <55A91CFD.8090900@citrix.com> <55A93D9802000078000928CD@mail.emea.novell.com> <55ACFAEC.50400@citrix.com> <55AD1ABE02000078000931F5@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55AD1ABE02000078000931F5@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Andrew Cooper Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 20/07/15 14:58, Jan Beulich wrote: >>>> On 20.07.15 at 15:43, wrote: >> On 17/07/15 16:38, Jan Beulich wrote: >>>>>> On 17.07.15 at 17:19, wrote: >>>> On 17/07/15 15:20, Jan Beulich wrote: >>>>> If not, then method 2 would seem quite a bit less troublesome than >>>>> method 1, yet method 3 would (even if more involved in terms of >>>>> changes to be done) perhaps result in the most elegant result. >>>> I agree that method three is more elegant. If both you and Andrew are ok >>>> with going in a per-vcpu stack direction for Xen in general then I'll >>>> write a per-vcpu patch first and then do another patch which adds the >>>> ring 3 feature on-top of that. >>> Actually improvements to common/wait.c have also been thought of >>> long ago already, for whenever per-vCPU stacks would be available. >>> The few users of these interfaces never resulted in this becoming >>> important enough a work item, unfortunately. >> While per-vcpu stacks would be nice, there are a number of challenges to >> be overcome before they can sensibly be used. Off the top of my head, >> per-vcpu state living at the top of the stack, hard coded stack >> addresses in the emulation stubs, IST stacks moving back onto the >> primary stack and splitting out a separate irq stack if the ring0 stack >> wants to be left with partial state on. >> >> Therefore I recommend method 2 to reuse the existing kudge we have. >> That will allow you to actually investigate some of the depriv aspects >> in the time you have. > Yeah, I too meant to point out that this per-pCPU stack work is > likely too much to be done as a preparatory thing here; I simply > forgot. > > Jan > Ok. It sounds like I should go with method two in that case. Thanks for the feedback! Ben