Maybe Kevin or Christoph (cc'ed) can help. Mathias Krause <mathias.kra...@secunet.com> writes:
> On 24.09.2010 14:47, Markus Armbruster wrote: >> Mathias Krause <mathias.kra...@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?