[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine |
Date: |
Wed, 26 Sep 2012 10:56:07 +0200 |
On 26.09.2012, at 03:18, David Gibson <address@hidden> wrote:
> On Wed, Sep 26, 2012 at 03:03:10AM +0200, Alexander Graf wrote:
>> On 26.09.2012, at 02:27, David Gibson wrote:
>>> On Mon, Sep 24, 2012 at 12:38:59PM +0200, Alexander Graf wrote:
>>>> On 24.09.2012, at 02:31, David Gibson wrote:
> [snip]
>>>>> So, if you look at the patch there is actually a -device form within
>>>>> there, the machine option is a wrapper around it. Without the machine
>>>>> option, I don't see how to get the desired properties for the
>>>>> configuration that is:
>>>>> * NVRAM is always instantiated by default (even if it's
>>>>> non-persistent)
>>>>> * It's easy to set the drive for that always-present NVRAM
>>>>
>>>> I suppose the idea is that when creating a machine from a qtree
>>>> dump, we can still recreate it. Or maybe when using -nodefaults? Not
>>>> sure. But the way you do it right now is very close to how we want
>>>> to model USB too, so I do like it. It's consistent.
>>>
>>> I really don't follow what point you're making here.
>>>
>>> The problem with -device syntax for my purpose is that with *no* extra
>>> command line arguments we should always have some sort of NVRAM - it's
>>> mandated by the platform spec, and should always be there, just like
>>> the PCI bridge and VIO bridge. That means instantiating the device
>>> from the machine setup code. But then, using -device will create a
>>> second instance of the device, which is no good, because only one can
>>> actually be used.
>>
>> What I'm trying to say is that the machine file should create a
>> device. Always in the case of PAPR. But I suppose pseudo-code is
>> easier to read:
>>
>> spapr.c:
>>
>> create_device("spapr-nvram", drive=machine_opts["nvram"]);
>
> Ok. That's what I do now.
>
>> spapr-nvram:
>>
>> if (!drive || checksum_is_bad(drive))
>> autogenerate_nvram_contents();
>
> Actually, I'm planning for the initialization of the content to be
> done from the guest firmware.
Does the guest have all information necessary to construct a workable nvram
image? If so, then yes, that's even better.
Alex
>
>
>> Then we can later add in vl.c:
>>
>> case OPTION_nvram:
>> create_drive("nvram", option);
>> machine_opts["nvram"] = drive["nvram"];
>
> Ok, that all works for me.
>
> Blue, does that seem reasonable to you?
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, (continued)
Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, David Gibson, 2012/09/23
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, Alexander Graf, 2012/09/24
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, David Gibson, 2012/09/25
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, Alexander Graf, 2012/09/25
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, David Gibson, 2012/09/25
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine,
Alexander Graf <=
- Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine, Thomas Huth, 2012/09/27
Re: [Qemu-devel] RFC: NVRAM for pseries machine, Alexander Graf, 2012/09/24