qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [PATCH] hw/vfio/pci-quirks: Fix broken legacy IGD passthrough
Date: Wed, 10 Jun 2020 11:03:39 +0200	[thread overview]
Message-ID: <04979308-3a35-4e40-35c7-836a36e47143@redhat.com> (raw)
In-Reply-To: <4bdc918a-a59c-a877-680a-2925c09fc736@redhat.com>

On 10/06/2020 10.25, Philippe Mathieu-Daudé wrote:
> On 6/10/20 9:59 AM, Thomas Huth wrote:
>> On 10/06/2020 09.53, Philippe Mathieu-Daudé wrote:
>>> On 6/10/20 9:50 AM, Thomas Huth wrote:
>>>> On 10/06/2020 09.31, Philippe Mathieu-Daudé wrote:
>>>>> On 6/10/20 5:51 AM, Thomas Huth wrote:
>>>>>> The #ifdef CONFIG_VFIO_IGD in pci-quirks.c is not working since the
>>>>>> required header config-devices.h is not included, so that the legacy
>>>>>> IGD passthrough is currently broken. Let's include the right header
>>>>>> to fix this issue.
>>>>>>
>>>>>> Buglink: https://bugs.launchpad.net/qemu/+bug/1882784
>>>>>> Fixes: 29d62771c81d8fd244a67c14a1d968c268d3fb19
>>>>>>        ("hw/vfio: Move the IGD quirk code to a separate file")
>>>>>
>>>>> What about shorter tag?
>>>>>
>>>>> Fixes: 29d62771c81 ("vfio: Move the IGD quirk code to a separate file")
>>>>
>>>> I always forget whether to use the short or the long version for
>>>> "Fixes:" ... this can hopefully be fixed (if necessary) when the patch
>>>> gets picked up.
>>>>
>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>>> ---
>>>>>>  hw/vfio/pci-quirks.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
>>>>>> index f2155ddb1d..3158390db1 100644
>>>>>> --- a/hw/vfio/pci-quirks.c
>>>>>> +++ b/hw/vfio/pci-quirks.c
>>>>>> @@ -11,6 +11,7 @@
>>>>>>   */
>>>>>>  
>>>>>>  #include "qemu/osdep.h"
>>>>>> +#include "config-devices.h"
>>>>>
>>>>> I've been wondering how we can avoid that mistake in the
>>>>> future, but can find anything beside human review.
>>>>
>>>> I think in the long term, we should include config-devices.h in osdep.h,
>>>> just like config-host.h and config-target.h is already included there.
>>>> Everything else is just too confusing. But then we should also add a
>>>> mechanism to poison the switches from config-devices.h in common code...
>>>
>>> We only need it for the files under hw/, right?
>>
>> qtest.c in the main directory includes it, too.
> 
> hw/ and qtests could include "hw/hw.h" instead of affecting all the
> codebase via "qemu/osdep.h".

I don't think that's a good idea - in that case, you have to make sure
to include hw/hw.h everywhere again, so you don't gain that much
compared to including config-devices.h directly everywhere. osdep.h is
our header that has to be included everywhere, so if we want to make
sure that these defines are available everywhere, we have to include it
from osdep.h.
Apart from that, hw/hw.h just contains one more prototype - which likely
should be renamed to cpu_hw_error() and moved to a cpu header instead,
so that we can finally delete hw/hw.h completely.

 Thomas



  reply	other threads:[~2020-06-10  9:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10  3:51 [PATCH] hw/vfio/pci-quirks: Fix broken legacy IGD passthrough Thomas Huth
2020-06-10  7:31 ` Philippe Mathieu-Daudé
2020-06-10  7:50   ` Thomas Huth
2020-06-10  7:53     ` Philippe Mathieu-Daudé
2020-06-10  7:59       ` Thomas Huth
2020-06-10  8:25         ` Philippe Mathieu-Daudé
2020-06-10  9:03           ` Thomas Huth [this message]
2020-06-10 10:08             ` Philippe Mathieu-Daudé
2020-06-11 17:35         ` Alex Williamson
2020-06-10 13:16     ` Laurent Vivier
2020-06-10 14:10       ` Thomas Huth
2020-08-12  8:26       ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04979308-3a35-4e40-35c7-836a36e47143@redhat.com \
    --to=thuth@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).