Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Julien Grall <julien.grall@xxxxxxx>]

Hello Peng,

On 14/09/2016 02:31, Peng Fan wrote:
> On Tue, Sep 13, 2016 at 02:24:31PM +0100, Julien Grall wrote:
> > On 13/09/16 14:12, Peng Fan wrote:
> > > Hi Julien,
> > > On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote:
> > > > Hello Peng,
> > > >
> > > > On 13/09/16 13:55, Peng Fan wrote:
> > > > > On AArch64 SoCs, some IPs may only have the capability to access
> > > > > 32bits address space. The physical memory assigned for Dom0 maybe
> > > > > not in 4GB address space, then the IPs will not work properly.
> > > > >
> > > > > Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
> > > > > to xen. It means how much memory user would like to be allocated
> > > > > in lower 4GB memory space. If there is not enough memory for
> > > > > dom0_lowmem, higher memory will be allocated.
> > > > >
> > > > > Thinking such a memory layout on an AArch64 SoC:
> > > > > Region 0: 2GB(0x80000000 - 0xffffffff)
> > > > > Region 1: 4GB(0x880000000 - 0x97fffffff)
> > > > > If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
> > > > > in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.
> > > > >
> > > > > Signed-off-by: Peng Fan <peng.fan@xxxxxxx>
> > > > > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > > Cc: Julien Grall <julien.grall@xxxxxxx>
> > > > > ---
> > > > >
> > > > > This patch is to resolve the issue mentioned in
> > > > > https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
> > > > > This patch not tested on latest 4.8-unstable, I only tested similar
> > > > > patch on xen 4.7 on AArch64 platform.
> > > > Please test any patch send upstream on 4.8-unstable. The code may have
> > > > changed.
> > > I have rebase this patch based on 4.8-unstable.
> > > latest commit:
> > > "
> > > commit a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
> > > Author: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
> > > Date:   Mon Aug 1 11:59:14 2016 -0600
> > >
> > >    arm/vm_event: get/set registers
> > > "
> > >
> > > Since I have not rebased my platform patches to 4.8-unstable, so have not 
> > > tested.
> > >
> > > Please kindly comments whether introudcing "dom0_lowmem" is acceptable or not
> > > to resolve the issue I met in 
> > > https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html.
> > >
> > > I'll rebase my platform patches and do some test.
> > >
> > > > > The idea of patch is that user could specify the lowmem that user would
> > > > > like to use. I rethought the ideas in 
> > > > > https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
> > > > > but that is not good. lowmem is precise, it maybe used for some IPs that maybe
> > > > > passthrough to DomU, so we only allocate the needed memory for Dom0.
> > > > Why? IPs passthrough to DomU will have to be protected by an SMMU so it does
> > > > not matter whether Dom0 is using all the lowmem or not.
> > > I just think there maybe some cases that some physical memory need to be
> > > reserved for DomU usage.
> > > SMMU is not a must when we passthrough a non DMA capable device to DomU.
> > > So I think an DRAM area can be encoded in dts, and passthrough to DomU.
> > How do you make sure that DomU will program the device with the correct
> > address? A malicious DomU could decide to use a physical address belonging to
> > another DomU or even Xen and would be able to read/write on it.
> When I debug DomU, I use a uart port as an early console for DomU.
> I just marked the uart with xen,passthrough and status disabled in Dom0 dts,
> then in DomU dts, I create a uart node, and in xl cfg, I mapped the address
> space. I did not use SMMU here. Just mapped the uart physical address
> to DomU uart guest physical address. And DomU can access the uart for my
> debug usage.
That's a different use case which does not involve UART reading directly 
the memory. Hence, there is no obligation to allocate lowmem for DomU.
Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel