Re: [Qemu-devel] [PATCH] CMOS file support

[Markus Armbruster <armbru@redhat.com>]

Maybe Kevin or Christoph (cc'ed) can help.

Mathias Krause <mathias.krause@secunet.com> writes:

> On 24.09.2010 14:47, Markus Armbruster wrote:
>> Mathias Krause <mathias.krause@secunet.com> writes:
>> 
>>> On 17.09.2010 15:27, Anthony Liguori wrote:
>>>> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>>>>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>>>>   
>>>>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write
>>>>>> the data.
>>>>>>      
>>>>> I'll fix that as soon as I figured how to use this interface.
>>>>>
>>>>>   
>>>>>> I think it would be very nice to add write support too so that writes to
>>>>>> CMOS were persisted across boots.
>>>>>>      
>>>>> Indeed. Also I would like to have a command line interface like '-cmos
>>>>> cmos.bin' instead of the ugly '-global mc146818rtc.file=cmos.bin'. But
>>>>> I'm not aware how to create such an alias. Any pointers?
>>>>>    
>>>> Unfortunately, it's a little complicated although it should get better
>>>> in the future.   The right way to do this today would be:
>>>>
>>>>   -drive file=cmos.bin,if=none,id=nvram -global mc146818rtc.drive=nvram
>>>>
>>>> The use of -drive is historic.  We'll have a better option in the future
>>>> that will look something like:
>>>>
>>>>  -blockdev file=cmos.bin,id=nvram -global mc146818rtc.drive=nvram
>>> Well, I guess "better" lies in the eye of the beholder, then ;)
>>>
>>>
>>>> But in either case, I'd suggest adding an -nvram option that was:
>>>>
>>>>  -nvram <filename>
>>>>
>>>> Which would do:
>>>>
>>>>   drive_add(optarg, "if=none,id=nvram");
>>>>
>>>> And then in the RTC code, default drive to nvram.
>>> I managed to add the nvram option but how do I get a reference to the
>>> drive back in the RTC code? Would I just loop with drive_get(IF_NONE, 0,
>>> i) until the id of the returned drive is "nvram"? Doesn't sound right
>>> but I've found no better solution due to the lack of an
>>> drive_get_by_id() function.
>> 
>> Use DEFINE_PROP_DRIVE() to define mc146818rtc's property drive, and it's
>> automatic: qdev assigns a pointer to the BlockDriverState.
>
> That works quite well but now, by using the QEMU block layer, the file
> for the CMOS data must be a multiple of 512 bytes. Otherwise
> bdrv_pread() will fail because the driver only handles full blocks so
> truncates the 256 bytes to a block device with 0 blocks. Sadly the block
> size of 512 seems to be hardcoded or can it be changed on a per drive basis?