qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 0/2] e1000: add interrupt mitigation support


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v5 0/2] e1000: add interrupt mitigation support
Date: Thu, 01 Aug 2013 16:07:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

Am 01.08.2013 11:38, schrieb Stefan Hajnoczi:
> On Wed, Jul 31, 2013 at 03:39:05PM +0200, Vincenzo Maffione wrote:
>> Ok, but it's unclear how do you prefer to create and "empty"
>> PC_COMPAT_1_6 in Patch 1.
>> If you want to keep this declaration form
>>
>> [...]
>> .compat_props = (GlobalProperty[]) {
>>         PC_COMPAT_1_6,
>>         { /* end of list */ }
>>     },
>> [...]
>>
>> in the two pc_*_machine_v1_6 structs, I'm forced to define
>>
>> #define PC_COMPAT_1_6 { /*empty*/ }
>>
>> but then I can't extend PC_COMPAT_1_5 with PC_COMPAT_1_6 as "header"
>> (like you guys do for PC_COMPAT_1_5 and PC_COMPAT_1_4), because
>> otherwise PC_COMPAT_1_6 would act as a premature terminator for
>> PC_COMPAT_1_5 (right?).
>>
>> Should I extend PC_COMPAT_1_5 with PC_COMPAT_1_6 as a "tail", or
>> should I avoid extending it in the Patch 1, and do the extension in
>> Patch 2 (when I have a non-empty PC_COMPAT_1_6)?
> 
> You are right, (GlobalProperty[]) {, {...}} is not valid syntax.  In
> that case I would switch PC_COMPAT_1_6 into the e1000 interrupt
> mitigation patch.  That way the patches are bisectable.
> 
> You can still introduce the QEMU 1.7 pc machine type as a separate
> patch if you wish, but I no longer see a big win if PC_COMPAT_1_6 cannot
> be isolated from the e1000 change.
> 
> Andreas: Do you agree to do everything in a single patch?

I see now that it wouldn't work with an empty macro (unless we drop the
",{}" and then later have to remember to add it back, which may be even
worse; my main concern was having the property set in the actual patch
for bisecting and cherry-picking, so no objections from my side.

mst was the other candidate for needing compat_props for now-delayed ACPI.
Stefan, you haven't replied wrt VMXNET3 and MSI-X yet - that may be
another candidate if we can't break migration format as proposed.

But we can always introduce the same machine in several patches, we just
need to be careful with merging them to not get multiple 1.7 machines
and not to loose properties.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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