qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 00/22] legacy virtio support for cross-endian


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v9 00/22] legacy virtio support for cross-endian targets
Date: Sun, 29 Jun 2014 18:02:21 +0200


> Am 29.06.2014 um 17:13 schrieb "Michael S. Tsirkin" <address@hidden>:
> 
>> On Tue, Jun 24, 2014 at 07:06:58PM +0200, Greg Kurz wrote:
>> The current legacy virtio devices have a fundamental flaw: they all share
>> data between host and guest with guest endianness ordering. This is ok for
>> nearly all architectures that have fixed endianness. Unfortunately, it breaks
>> for recent PPC64 and ARM targets that can change endianness at runtime.
>> The virtio-1.0 specification fixes the issue by enforcing little-endian
>> ordering. It may take some time though until the code for 1.0 gets available
>> and supported, and all the users can migrate. There have been discussions
>> for some monthes about supporting such oddity: now we have little-endian
>> PPC64 distros available, it is worth to propose something.
>> 
>> This patch set brings legacy virtio support for cross-endian targets. The
>> rationale is that we add a new device_endianness property to VirtIODevice.
>> This property is used as a runtime indicator to decide wether we should
>> do little-endian or big-endian conversion, as opposed to the compile time
>> choice we have now with TARGTE_WORDS_BIGENDIAN. The choice was made to
>> sample the device endianness out of the endianness mode of the guest
>> CPU that does the reset. It is an evil but logical consequence of the
>> initial flaw in the virtio specification, and it was agreed that the concept
>> would be a good common base for ARM and PPC64 enablement at least. Please
>> note also that this new property is state and must be preserved across
>> migrations.
>> 
>> There are several parts in the serie:
>> - patches 1 and 2 are simple fixes
>> - patches 3 to 9 introduce VMState based subsections in the virtio
>>  migration code. This is needed because we introduce a new property
>>  in VirtIODevice that we want to migrate without ruining compatibility
>>  efforts
>> - patches 10 to 13 bring virtio device endianness and memory accessors
>>  to be used by the virtio code
>> - patches 14 to 20 wire the new memory accessors everywhere accross the
>>  virtio code
>> - patch 21 is the PPC64 enablement
>> - patch 22 is a follow-up workaround to disable vhost-net acceleration
>>  in the case the host and guest have different endianness, because
>>  it is not supported for the moment
>> 
>> Changes since v8 are provided in each patch.
>> 
>> Cheers.
> 
> Applied, thanks everyone.

Woohoo :).


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]