From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [Hackathon minutes] PV network improvements Date: Tue, 21 May 2013 09:31:07 +0100 Message-ID: <519B30CB.4010909@eu.citrix.com> References: <20130520183347.GI32007@zion.uk.xensource.com> <1369124555.21246.21.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1369124555.21246.21.camel@zakaz.uk.xensource.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: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 05/21/2013 09:22 AM, Ian Campbell wrote: > On Mon, 2013-05-20 at 19:33 +0100, Wei Liu wrote: >> On Mon, May 20, 2013 at 03:49:32PM +0100, George Dunlap wrote: >> [...] >>>> J) Map the whole physical memory of the machine in dom0 >>>> If mapping/unmapping or copying slows us down, could we just keep the >>>> whole physical memory of the machine mapped in dom0 (with corresponding >>>> IOMMU entries)? >>>> At that point the frontend could just pass mfn numbers to the backend, >>>> and the backend would already have them mapped. >>>> >From a security perspective it doesn't change anything when running >>>> the backend in dom0, because dom0 is already capable of mapping random >>>> pages of any guests. QEMU instances do that all the time. >>>> But it would take away one of the benefits of deploying driver domains: >>>> we wouldn't be able to run the backends at a lower privilege level. >>>> However it might still be worth considering as an option? The backend is >>>> still trusted and protected from the frontend, but the frontend wouldn't >>>> be protected from the backend. >>> >>> What's missing from this was my side of the discussion: >>> >>> I was saying that if TLB flushes from grant-unmap is indeed the >>> problem, then maybe we could have the *front-end* in charge of >>> requesting a TLB flush for its pages. The strict TLB flushing is to >>> protect a frontend from rogue back-ends from reading sensitive data; >>> if the front-end were willing to just not use the pages for a short >>> amount of time, and issue a flush say every second or so, that would >>> reduce the TLB flushes greatly while maintaining the safety advantages >>> of driver domains. >>> >> >> I'm not sure I get what you mean here. Are you saying DomU flushes >> Dom0's TLB entries? > > The gnt_unmap made by dom0 needs to flush the TLB of any physical > processor which may have seen the mapping, which means approximately all > dom0 vcpus. That's what I was getting at. It's Xen that does any actual TLB flushes, and for now the "promise" to the front-end is that the page is safe from the backend* after the transaction is done. But it would be nicer if we could batch these flushes to happen once every few hundred milliseconds, or even one a second. If we allowed the front-end to choose a new the interface, that said "the page is safe from the backend once you have made this hypercall", then guests could choose the "window" size based on their own parameters. * Remember that the point of grant maps isn't to allow *dom0* access to the guests; dom0 already has all the access it needs. It's to allow driver domains access to the guests. -George