Re: [Xen-devel] [PATCH FOR-4.5] xen: arm: Do not enable EFI in dom0 since it is not yet supported.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2014-10-14 at 14:18 +0100, Julien Grall wrote:
> On 10/14/2014 02:07 PM, Ian Campbell wrote:
> > On Tue, 2014-10-14 at 13:58 +0100, Julien Grall wrote:
> >> On 10/14/2014 01:49 PM, Ian Campbell wrote:
> >>> On Tue, 2014-10-14 at 13:28 +0100, Julien Grall wrote:
> >>>> Hi Ian,
> >>>>
> >>>> On 10/14/2014 08:21 AM, Ian Campbell wrote:
> >>>>> On Mon, 2014-10-13 at 12:37 -0700, Roy Franz wrote:
> >>>>>> On Mon, Oct 13, 2014 at 9:20 AM, Julien Grall 
> >>>>>> <julien.grall@xxxxxxxxxx> wrote:
> >>>>>>> (CC vijay)
> >>>>>>>
> >>>>>>> Hi Suravee,
> >>>>>>>
> >>>>>>> On 10/13/2014 05:17 PM, suravee.suthikulpanit@xxxxxxx wrote:
> >>>>>>>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx>
> >>>>>>>>
> >>>>>>>> Since EFI is not yet supported in dom0, we need to remove the 
> >>>>>>>> following
> >>>>>>>> properties from the chosen node:
> >>>>>>>>
> >>>>>>>>   * linux,uefi-mmap-start
> >>>>>>>>   * linux,uefi-mmap-size
> >>>>>>>>   * linux,uefi-mmap-desc-size
> >>>>>>>>   * linux,uefi-mmap-desc-ver
> >>>>>>>>
> >>>>>>>> These are added by "arch/arm/efi/efi-boot.h: fdt_add_uefi_nodes()",
> >>>>>>>> and used by dom0 kernel to enable EFI.
> >>>>>>>>
> >>>>>>>> Cc: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>>>>>> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >>>>>>>> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>>>>>>> Cc: Roy Franz <roy.franz@xxxxxxxxxx>
> >>>>>>>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> >>>>>>>
> >>>>>>> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>>>>
> >>>>>> Reviewed-by: Roy Franz <roy.franz@xxxxxxxxxx>
> >>>>>
> >>>>> Acked-by: Ian Campbell <ian.campbell@.citrix.com>
> >>>>>
> >>>>> But I do wonder why we don't just drop the hos /chosen node -- I think
> >>>>> everything which should be in there is fabricated by the h/visor anyway.
> >>>>
> >>>> I though about the same things yesterday, but the /chosen node may
> >>>> contain other properties (such as OS specific) that we may need to pass
> >>>> to DOM0.
> >>>
> >>> What sort of thing are you thinking of here?
> >>
> >> FreeBSD provides two properties (stdin and stdout) to choose the input
> >> and the output methods.
> >>
> >> Those properties need to be copied in DOM0 DT to allow the user chose
> >> which console he wants to use (think about a platform with 2 serial ports).
> > 
> > How do you know whether stdin/stdout were intended to apply to dom0 or
> > Xen?
> 
> We specify the console for Xen via the Xen command line.
> 
> > What if dom0 wants to use hvc0? How is that expressed?
> 
> For now it has the priority against anything else. But in ideal world,
> the HVC console should be describe in a device node add by Xen.
> 
> > It seems to me that if bootargs is being consumed by Xen then
> > stdin/stdout ought to be consumed by Xen for consistency.
> 
> stdin/stdout is part of FreeBSD command line. If we use those
> properties, why don't we parse Linux command line to get the console?
> 

OK. I'm confused. I was talking about device-tree properties
under /chosen so I thought you were saying that stdin/stdout were such
things. If they are part of the bsd command line (i.e. part of
xen,dom0-bootargs or similar) then there is no problem -- we pass them
through just like we do today.

> > Which points to special handling for stdin/stdout in Xen, i.e. a
> > continuation of the whitelisting approach.
> 
> And how do you chose the console for DOM0? For Linux we have to use
> console=hvc0 on the command line. FreeBSD choose to use stdin/stdout.

Are you now saying that they aren't in the FreeBSD command line but are
properties?

If you are saying that they are dt properties then stdin/stdout should
be handled just like bootargs IMHO, not simply happen to work due to a
partial blacklist

Ian.


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