All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Hackathon minutes] PV network improvements
Date: Tue, 21 May 2013 09:31:07 +0100	[thread overview]
Message-ID: <519B30CB.4010909@eu.citrix.com> (raw)
In-Reply-To: <1369124555.21246.21.camel@zakaz.uk.xensource.com>

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

  reply	other threads:[~2013-05-21  8:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 14:08 [Hackathon minutes] PV network improvements Stefano Stabellini
2013-05-20 14:49 ` George Dunlap
2013-05-20 18:33   ` Wei Liu
2013-05-21  8:22     ` Ian Campbell
2013-05-21  8:31       ` George Dunlap [this message]
2013-05-20 18:31 ` Wei Liu
2013-05-21  8:31   ` Ian Campbell
2013-05-21  9:26   ` Tim Deegan
2013-05-21  9:39     ` Wei Liu
2013-05-21 10:11       ` Tim Deegan
2013-05-21 10:01     ` George Dunlap
2013-05-21 10:06       ` Wei Liu
2013-05-21 10:51     ` Stefano Stabellini
2013-05-21 12:52       ` Konrad Rzeszutek Wilk
2013-05-21 13:32         ` Stefano Stabellini
2013-05-21 13:42       ` Tim Deegan
2013-05-21 16:58         ` Stefano Stabellini
2013-05-22  9:52           ` Tim Deegan
2013-05-22  9:55           ` Ian Campbell
2013-05-20 19:36 ` annie li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519B30CB.4010909@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.