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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.