All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: qemu-devel@nongnu.org
Cc: borntraeger@de.ibm.com, agraf@suse.de, thuth@redhat.com,
	david@redhat.com, pmorel@linux.vnet.ibm.com,
	zyimin@linux.vnet.ibm.com, Greg Kurz <groug@kaod.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v4 0/9] s390x: zPCI detangling
Date: Tue, 8 Aug 2017 11:15:42 +0200	[thread overview]
Message-ID: <20170808111542.16422571@gondolin> (raw)
In-Reply-To: <20170804165934.4d6fb98f@gondolin>

On Fri, 4 Aug 2017 16:59:34 +0200
Cornelia Huck <cohuck@redhat.com> wrote:

> On Fri,  4 Aug 2017 13:29:37 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > Next version, not so many changes from v3.
> > 
> > As you might have guessed, the goals are still the same:
> > - Being able to disable PCI support in a build completely.
> > - Properly fencing off PCI if the relevant facility bit is not provided.
> > 
> > Changes v3->v4:
> > - introduce pci_available boolean
> > - use pci_available to fence off setting the zcpi facility bit
> > - collected tags
> > 
> > Branch is still git://github.com/cohuck/qemu no-zpci-cpumodel  
> 
> make check on a build with pci disabled revealed an interesting
> inconsistency: We create a virtio-9p-ccw device, but the base
> virtio-9p-device is in code that is not built for !pci.
> 
> If I remove the pci dependency for hw/9pfs/ and fsdev/, things look
> fine (at least on s390x). We probably need a different dependency,
> though.
> 
> virtio-9p maintainers, any suggestions?

I have the patch below, which is ugly, but seems to work for me. Better
ideas welcome :)

From 0ba6427e7ac7cef38b487d28c9dce653d8cb9a71 Mon Sep 17 00:00:00 2001
From: Cornelia Huck <cohuck@redhat.com>
Date: Tue, 8 Aug 2017 11:03:38 +0200
Subject: [PATCH] 9pfs: fix dependencies

Nothing in fsdev/ or hw/9pfs/ depends on pci; it should rather depend
on CONFIG_VIRTFS and on the presence of an appropriate virtio transport
device.

Let's introduce CONFIG_VIRTIO_CCW to cover s390x and check for
CONFIG_VIRTFS && (CONFIG_VIRTIO_PCI || CONFIG_VIRTIO_CCW).

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
 default-configs/s390x-softmmu.mak | 1 +
 fsdev/Makefile.objs               | 9 +++------
 hw/Makefile.objs                  | 2 +-
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/default-configs/s390x-softmmu.mak b/default-configs/s390x-softmmu.mak
index 6ab2bc65ac..7f15ab68b1 100644
--- a/default-configs/s390x-softmmu.mak
+++ b/default-configs/s390x-softmmu.mak
@@ -8,3 +8,4 @@ CONFIG_S390_FLIC=y
 CONFIG_S390_FLIC_KVM=$(CONFIG_KVM)
 CONFIG_VFIO_CCW=$(CONFIG_LINUX)
 CONFIG_WDT_DIAG288=y
+CONFIG_VIRTIO_CCW=y
diff --git a/fsdev/Makefile.objs b/fsdev/Makefile.objs
index 659df6e187..10d8caa291 100644
--- a/fsdev/Makefile.objs
+++ b/fsdev/Makefile.objs
@@ -1,10 +1,7 @@
-ifeq ($(CONFIG_VIRTIO)$(CONFIG_VIRTFS)$(CONFIG_PCI),yyy)
 # Lots of the fsdev/9pcode is pulled in by vl.c via qemu_fsdev_add.
-# only pull in the actual virtio-9p device if we also enabled virtio.
-common-obj-y = qemu-fsdev.o 9p-marshal.o 9p-iov-marshal.o
-else
-common-obj-y = qemu-fsdev-dummy.o
-endif
+# only pull in the actual virtio-9p device if we also enabled a virtio backend.
+common-obj-$(call land, $(CONFIG_VIRTFS),$(call lor, $(CONFIG_VIRTIO_PCI),$(CONFIG_VIRTIO_CCW)))= qemu-fsdev.o 9p-marshal.o 9p-iov-marshal.o
+common-obj-$(call lnot, $(call land, $(CONFIG_VIRTFS),$(call lor, $(CONFIG_VIRTIO_PCI),$(CONFIG_VIRTIO_CCW)))) = qemu-fsdev-dummy.o
 common-obj-y += qemu-fsdev-opts.o qemu-fsdev-throttle.o
 
 # Toplevel always builds this; targets without virtio will put it in
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index a2c61f6b09..10942fe0b4 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -1,4 +1,4 @@
-devices-dirs-$(call land, $(CONFIG_VIRTIO),$(call land,$(CONFIG_VIRTFS),$(CONFIG_PCI))) += 9pfs/
+devices-dirs-$(call land, $(CONFIG_VIRTFS),$(call lor,$(CONFIG_VIRTIO_PCI),$(CONFIG_VIRTIO_CCW))) += 9pfs/
 devices-dirs-$(CONFIG_SOFTMMU) += acpi/
 devices-dirs-$(CONFIG_SOFTMMU) += adc/
 devices-dirs-$(CONFIG_SOFTMMU) += audio/
-- 
2.13.4

  reply	other threads:[~2017-08-08  9:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 11:29 [Qemu-devel] [PATCH v4 0/9] s390x: zPCI detangling Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 1/9] kvm: remove hard dependency on pci Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 2/9] s390x/pci: add stubs Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 3/9] s390x: chsc nt2 events are pci-only Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 4/9] s390x/pci: do not advertise pci on non-pci builds Cornelia Huck
2017-08-04 13:21   ` David Hildenbrand
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 5/9] s390x/ccw: create s390 phb conditionally Cornelia Huck
2017-08-04 13:20   ` David Hildenbrand
2017-08-07 10:00     ` Cornelia Huck
2017-08-07 10:21       ` David Hildenbrand
2017-08-07 11:11         ` Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 6/9] s390x/sclp: properly guard pci-specific functions Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 7/9] s390x/pci: fence off instructions for non-pci Cornelia Huck
2017-08-04 13:17   ` David Hildenbrand
2017-08-07  9:52     ` Cornelia Huck
2017-08-07 14:17       ` David Hildenbrand
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 8/9] s390x/kvm: msi route fixup " Cornelia Huck
2017-08-04 13:18   ` David Hildenbrand
2017-08-07  9:54     ` Cornelia Huck
2017-08-04 11:29 ` [Qemu-devel] [PATCH v4 9/9] s390x: refine pci dependencies Cornelia Huck
2017-08-04 13:25   ` David Hildenbrand
2017-08-04 14:59 ` [Qemu-devel] [PATCH v4 0/9] s390x: zPCI detangling Cornelia Huck
2017-08-08  9:15   ` Cornelia Huck [this message]
2017-08-08  9:29     ` Thomas Huth
2017-08-08  9:46       ` Cornelia Huck
2017-08-08 10:42         ` Thomas Huth

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=20170808111542.16422571@gondolin \
    --to=cohuck@redhat.com \
    --cc=agraf@suse.de \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=groug@kaod.org \
    --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.