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

Re: [RFC] design: design doc for 1:1 direct-map


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Fam Zheng <fam@xxxxxxxxxx>
  • Date: Tue, 08 Dec 2020 11:23:44 +0000
  • Arc-authentication-results: i=1; mx.zoho.com.cn; dkim=pass header.i=euphon.net; spf=pass smtp.mailfrom=fam@xxxxxxxxxx; dmarc=pass header.from=<fam@xxxxxxxxxx> header.from=<fam@xxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com.cn; s=zohoarc; t=1607426635; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=1iOZu/bWRMc27o2XpZheBxvCkC5w68WGiu3hg1+B8lQ=; b=b4xLFSTjd7Hhus4LQFiY1pThbEQwpUafIZYwqOm0ETjqZBaUeGV2sUUIFNzAEzjpC2C4okPTLy9QsWYQ9SQQIj7pqogGWFy9u2mQ5HGo2C5SA8DHrl8A5sljcJk9DYBpOScx/uUneoIh2WM2sLnPeBPCGAx7H3/akm2V0rhdmiA=
  • Arc-seal: i=1; a=rsa-sha256; t=1607426635; cv=none; d=zoho.com.cn; s=zohoarc; b=VNfiMeLzy3SgXCtOR7yczQs1cHlee/laXPOCDvB+3b0J8Wmsc2J57BPOueD/fnZPtyH9hqhoAN0eRzXdmGrQVWkFNPoFV4YBJenZJjXipZF+OyT0FvLKfm7F9cAka1Wv8kEr6oik43/N5YUftY+QbrKWmZR9/PMQaXcFNa6aycw=
  • Cc: Julien Grall <julien@xxxxxxx>, Bertrand.Marquis@xxxxxxx, Kaly.Xin@xxxxxxx, Wei.Chen@xxxxxxx, nd@xxxxxxx, Paul Durrant <paul@xxxxxxx>, Penny Zheng <penny.zheng@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, sstabellini@xxxxxxxxxx
  • Delivery-date: Tue, 08 Dec 2020 11:24:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, 2020-12-08 at 11:53 +0100, Jan Beulich wrote:
> On 08.12.2020 11:22, Fam Zheng wrote:
> > On 2020-12-08 10:12, Jan Beulich wrote:
> > > On 08.12.2020 10:07, Julien Grall wrote:
> > > > On 08/12/2020 05:21, Penny Zheng wrote:
> > > > > --- /dev/null
> > > > > +++ b/docs/designs/1_1_direct-map.md
> > > > > @@ -0,0 +1,87 @@
> > > > > +# Preface
> > > > > +
> > > > > +The document is an early draft for direct-map memory map
> > > > > +(`guest physical == physical`) of domUs. And right now, it
> > > > > constrains to ARM
> > > > 
> > > > s/constrains/limited/
> > > > 
> > > > Aside the interface to the user, you should be able to re-use
> > > > the same 
> > > > code on x86. Note that because the memory layout on x86 is
> > > > fixed (always 
> > > > starting at 0), you would only be able to have only one direct-
> > > > mapped 
> > > > domain.
> > > 
> > > Even one seems challenging, if it's truly meant to have all of
> > > the
> > > domain's memory direct-mapped: The use of space in the first Mb
> > > is
> > > different between host and guest.
> > 
> > Speaking about the case of x86, we can still direct-map the ram
> > regions
> > to the single direct-mapped DomU because neither Xen nor dom0
> > require
> > those low mem.
> > 
> > We don't worry about (i.e. don't direct-map) non-ram regions (or
> > any
> > range that is not reported as usable ram from DomU's PoV (dictated
> > by
> > e820 table), so those can be MMIO or arbitrary mapping with EPT.
> 
> For one, the very first page is considered special in x86 Xen. No
> guest should gain access to MFN 0, unless you first audit all
> code and address all the issues you find. And then there's also
> Xen's low-memory trampoline living there. Plus besides the BDA
> (at real-mode address 0040:0000) I suppose the EBDA also shouldn't
> be exposed to a guest, nor anything else that the host finds
> reserved in E820. IOW it would be the host E820 to dictate some
> of the guest E820 in such a case.
> 

You're right about the trampoline area, it has to be specially taken
care of. Not a problem if we could disable cpu hotplug. I don't think
the guest will ever try to DMA from/to MFN 0, BDA or EBDA, so even not
direct mapping those should not make any functional difference.

In general, I agree the guest E820 as well as all direct mapping areas
mustn't break out of host E820 limitation, otherwise it will not work.

Fam




 


Rackspace

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