From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52627 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ozy5L-0007Qs-Ta
	for qemu-devel@nongnu.org; Sun, 26 Sep 2010 16:44:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <Mathias.Krause@secunet.com>) id 1Ozy5K-0006Jc-FN
	for qemu-devel@nongnu.org; Sun, 26 Sep 2010 16:44:35 -0400
Received: from a.mx.secunet.com ([195.81.216.161]:60887)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <Mathias.Krause@secunet.com>) id 1Ozy5K-0006JJ-3t
	for qemu-devel@nongnu.org; Sun, 26 Sep 2010 16:44:34 -0400
Message-ID: <4C9FB0A4.4030303@secunet.com>
Date: Sun, 26 Sep 2010 22:44:20 +0200
From: Mathias Krause <mathias.krause@secunet.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] CMOS file support
References: <1284645517-32743-1-git-send-email-mathias.krause@secunet.com>	<4C9251C6.2090705@codemonkey.ws>
	<4C930F9B.5010007@secunet.com>	<4C936CDC.1030207@codemonkey.ws>
	<4C9A5C61.7030508@secunet.com>
	<m3lj6rz4tk.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3lj6rz4tk.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org

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