qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 2/3] Assume PPC64 host on PPC32 KVM


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 2/3] Assume PPC64 host on PPC32 KVM
Date: Fri, 24 Jul 2009 15:15:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Alexander Graf wrote:
> 
> On 24.07.2009, at 14:57, Jan Kiszka wrote:
> 
>> Alexander Graf wrote:
>>>
>>> On 24.07.2009, at 13:51, Jan Kiszka wrote:
>>>
> 
> [...]
> 
>>> There are no 32-bit PowerPC KVM kernels that can do dirty logging.
>>
>> By design or by lack of implementation?
> 
> Lack of implementation.
> 
>> And what if some other arch with support for both pops up? #ifdef
>> HOST_PPC is no long-term solutions. And I see no need to install a
>> temporary workaround given the currently existing kernel support.
> 
> I'd like to have the qemu bits sorted out while polishing the kvm parts,
> so when kvm support shows up mainline there's a working userspace part.

I understand. But the risk is that what you submit to qemu and kvm may
receive different reviews and finally look different. So for stuff which
concerns not yet existing (or fully implemented) interfaces, the other
way around is better. Specifically if there is a "risk" that it makes
into a qemu release before the corresponding kernel bits are official.

> 
>>>> In any case, I suggest to pin down the word size and use it for all
>>>> hosts.
>>>
>>> That would break backwards compatibility.
>>
>> x86 and ia64 are little endian for which is doesn't matter, PowerPC and
>> s390 don't support dirty logging so far. Or what would break?
> 
> Oh you mean just always use u32* and be done with it?
> 

Or u64* as you suggested. It doesn't matter for existing support, and
future support should simply use that type even on 32-bit hosts.

> Sounds appealing...
> 
> Alex
> 

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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