qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 00/37] pci, pc, virtio: features, fixes


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PULL 00/37] pci, pc, virtio: features, fixes
Date: Fri, 17 May 2019 10:14:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/17/19 5:12 AM, Wei Yang wrote:
> On Fri, May 17, 2019 at 10:59:03AM +0800, Wei Yang wrote:
>> On Thu, May 16, 2019 at 08:53:04PM +0200, Philippe Mathieu-Daudé wrote:
>>> On Thu, May 16, 2019 at 8:33 PM Philippe Mathieu-Daudé
>>> <address@hidden> wrote:
>>>> On 5/16/19 6:04 PM, Peter Maydell wrote:
>>>>> On Thu, 16 May 2019 at 13:17, Michael S. Tsirkin <address@hidden> wrote:
>>>>>>
>>>>>> The following changes since commit 
>>>>>> efb4f3b62c69383a7308d7b739a3193e7c0ccae8:
>>>>>>
>>>>>>   Merge remote-tracking branch 
>>>>>> 'remotes/stefanha/tags/block-pull-request' into staging (2019-05-10 
>>>>>> 14:49:36 +0100)
>>>>>>
>>>>>> are available in the Git repository at:
>>>>>>
>>>>>>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>>>>>>
>>>>>> for you to fetch changes up to 0534d255dae78450d90d59db0f3a9a46b32ebd73:
>>>>>>
>>>>>>   tests: acpi: print error unable to dump ACPI table during rebuild 
>>>>>> (2019-05-14 21:19:14 -0400)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> pci, pc, virtio: features, fixes
>>>>>>
>>>>>> reconnect for vhost blk
>>>>>> tests for UEFI
>>>>>> misc other stuff
>>>>>>
>>>>>> Signed-off-by: Michael S. Tsirkin <address@hidden>
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>
>>>>> Hi -- this pullreq has a conflict in default-configs/arm-softmmu.mak
>>>>> because the conversion of arm to Kconfig has landed in master.
>>>>> Could you rebase and fix up to use whatever the Kconfig
>>>>> equivalent of these changes is, please?
>>>>
>>>> Culprit is "hw/acpi: Consolidate build_mcfg to pci.c"
>>>>
>>>> The conflict doesn't look trivial to resolve (to me) so I'd rather see
>>>> it reviewed (by Thomas). I suggest to drop the patch(es) from your PR :(
>>>
>>> Thomas, FYI I did this to resolve the conflict:
>>>
>>> - keep default-configs/arm-softmmu.mak from master:
>>>
>>>  git checkout origin/master default-configs/arm-softmmu.mak
>>>
>>> - applied the following !fixup snippet:
>>>
>>> -- >8 --
>>> --- a/hw/acpi/Kconfig
>>> +++ b/hw/acpi/Kconfig
>>> @@ -25,7 +25,7 @@ config ACPI_NVDIMM
>>>
>>> config ACPI_PCI
>>>     bool
>>> -    depends on ACPI
>>> +    depends on ACPI && PCI
>>>
>>> ---
>>>
>>> I felt it easier to review on top of "hw/acpi: Improve build modularity"
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04718.html
>>>
>>
>> Well, I hope this will not block the merge.
>>
>> I took a look in the change of default-configs/arm-softmmu.mak. The general
>> idea from Thomas is put those hard-coded config to Kconfig.
>>
>> This is fine and what I need to change in my patch is to select ACPI_PCI in
>> the proper place, if my understanding is correct.
>>
>> Two things I need to fix:
>>
>>  * add select ACPI_PCI in proper place of hw/arm/Kconfig
>>  * add a dummy build_mcfg() for link when ACPI_PCI is not configured.
>>
>> Then I have two questions:
>>
>>  * In hw/arm/Kconfig, I don't see one option contains both PCI and ACPI. I am
>>    confused where to put the select.
>>  * put dummy build_mcfg() in aml-build.c works. Igor, do you like this? Or
>>    you haver other preference?
> 
> Hmm... put build_mcfg() in aml-build.c seems not work when we config both x86
> and arm. e.g. --target-list=x86_64-softmmu,arm-softmmu. Because we only have
> one aml-build.o object file.

I think this is what I tried to fix in "hw/acpi: Improve build modularity"
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04718.html

> 
> What comes into my mind is wrap build_mcfg() with #ifdef CONFIG_ACPI_PCI.
> 
> Any better idea?
> 
>>
>>> Sadly both series clash :(
>>>
>>> Regards,
>>>
>>> Phil.
>>
>> -- 
>> Wei Yang
>> Help you, Help me
> 



reply via email to

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