From: Cornelia Huck <cohuck@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, borntraeger@de.ibm.com, agraf@suse.de,
david@redhat.com, pmorel@linux.vnet.ibm.com,
zyimin@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3 1/9] kvm: remove hard dependency on pci
Date: Fri, 4 Aug 2017 11:56:07 +0200 [thread overview]
Message-ID: <20170804115607.40f8a6d8@gondolin> (raw)
In-Reply-To: <20170726102623.1d182c07@gondolin>
On Wed, 26 Jul 2017 10:26:23 +0200
Cornelia Huck <cohuck@redhat.com> wrote:
> On Wed, 26 Jul 2017 08:52:44 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> > Since this missed the 2.10 freeze anyway and we've got some more time to
> > discuss it: I still think it would be much cleaner to move the functions
> > from kvm-all.c that use these PCI functions into a separate file
> > kvm-pci.c instead and compile that only with CONFIG_PCI=y. That way we
> > likely also could prevent that more dependencies on CONFIG_PCI creep
> > into kvm-all.c again at later points in time.
> >
> > I've now had a closer look, and it seems like the only affected
> > functions are kvm_irqchip_add_msi_route() and
> > kvm_irqchip_update_msi_route() ... and these seems only to be used in
> > code we would not care about on s390x with CONFIG_PCI=n. So could you
> > please have at least a try to move these two functions (and other
> > related msi functions) to a new file kvm-pci.c instead to see whether
> > that would work, too?
>
> I can try, as this missed the 2.10 boat anyway.
>
> The code contains some parts that are not relevant in all cases (msi
> routes if we don't use pci, adapter routes for anything not
> s390x, ...), but I don't think trying to rip this out would be much of
> an improvement. I'll try the minimal (well, not quite as minimal as
> this patch) route instead.
I tried this; but it turned out to be one of those cases where you pull
on a stick and then find half a tree attached to it... Much of the code
is used by all routing variants, and I ended up exposing so many
functions that it was just ugly and unreadable.
The variant I'm now going with is keeping the original approach and
adding a pci_available variable, which I also use in the patch that
exposes the zpci facility patch only when pci is compiled in. I'll try
to post this after lunch.
next prev parent reply other threads:[~2017-08-04 9:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 15:33 [Qemu-devel] [PATCH v3 0/9] s390x: zPCI detangling Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 1/9] kvm: remove hard dependency on pci Cornelia Huck
2017-07-26 6:52 ` Thomas Huth
2017-07-26 8:26 ` Cornelia Huck
2017-08-04 9:56 ` Cornelia Huck [this message]
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 2/9] s390x/pci: add stubs Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 3/9] s390x: chsc nt2 events are pci-only Cornelia Huck
2017-07-26 6:59 ` Thomas Huth
2017-07-26 8:17 ` Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 4/9] s390x/pci: do not advertise pci on non-pci builds Cornelia Huck
2017-07-25 18:49 ` Christian Borntraeger
2017-07-26 7:00 ` Thomas Huth
2017-07-26 8:45 ` Yi Min Zhao
2017-07-26 9:28 ` David Hildenbrand
2017-07-26 10:09 ` Cornelia Huck
2017-07-26 11:18 ` Thomas Huth
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 5/9] s390x/ccw: create s390 phb conditionally Cornelia Huck
2017-07-26 10:10 ` Christian Borntraeger
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 6/9] s390x/sclp: properly guard pci-specific functions Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 7/9] s390x/pci: fence off instructions for non-pci Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 8/9] s390x/kvm: msi route fixup " Cornelia Huck
2017-07-26 7:09 ` Thomas Huth
2017-07-26 8:20 ` Cornelia Huck
2017-07-26 8:25 ` Thomas Huth
2017-07-26 8:37 ` David Hildenbrand
2017-07-26 9:58 ` Cornelia Huck
2017-07-25 15:33 ` [Qemu-devel] [PATCH v3 9/9] s390x: refine pci dependencies Cornelia Huck
2017-07-26 9:05 ` [Qemu-devel] [PATCH v3 0/9] s390x: zPCI detangling Christian Borntraeger
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=20170804115607.40f8a6d8@gondolin \
--to=cohuck@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=zyimin@linux.vnet.ibm.com \
/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).