qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI


From: Graeme Gregory
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Wed, 12 Nov 2014 11:38:08 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Nov 12, 2014 at 11:07:22AM +0000, Mark Rutland wrote:
> [...]
> 
> > > > > > We are currently suggesting adding an RDSP property to the chosen 
> > > > > > node
> > > > > > in the tiny DT, but a command-line arguement like kexec proposed 
> > > > > > could
> > > > > > be another option I guess, albeit not a very pretty one.
> > > > > 
> > > > > I'm not sure what an RDSP command line property would have to do with
> > > > > kexec. I'll assume I've misunderstood something.
> > > > > 
> > > > 
> > > > I thought the kexec patches proposed passing the RDSP on the
> > > > command-line to boot the secondary kernel, so if that ended up being
> > > > supported by the kernel for kexec, maybe that could be leveraged by
> > > > Xen's boot protocol.  It was an idea someone brought to me, just thought
> > > > I'd mention it.
> > > 
> > > Ah, that's not something I'd heard of.
> > 
> > Maybe there was a misunderstanding then, I thought you were cc'ed on
> > those discussions.
> 
> I may just have lost them in my inbox. I'm on a few too many mailing
> lists these days. Sorry about that.
> 
> > > I'm not a fan of placing fundamentally required system description on
> > > the command line. It's fine for explicit overrides but I don't think it
> > > should be the default mechanism as that causes its own set of problems
> > > (who wants to fight with their hypervisor to pass a command line to a
> > > guest kernel?).
> > > 
> > 
> > Agreed completely, but I've been lacking strong technical arguments
> > against passing this stuff on the cmdline.  My personal preferred
> > approach for the Xen Dom0 case is to add a property to the DT.
> 
> Something under /chosen, or a firmware node would sound preferable to
> me. For UEFI we pass the system table address as
> /chosen/linux,uefi-system-table = <... ...>, and I think the RDSP could
> be handled similarly if necessary. The user can than override that via
> the command line if desired.
> 
We have actually done that in the past when we had to support u-boot and
bootwrapper as a bootloader. It works fine in the kernel and its a
minimal patch to support.

Graeme




reply via email to

[Prev in Thread] Current Thread [Next in Thread]