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

[Mathias Krause <mathias.krause@secunet.com>]

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?


Regards,
Mathias