| Message ID | 20190122094143.8857-1-david@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] s390x/pci: Warn when adding PCI devices without the 'zpci' feature | expand |
On 2019-01-22 10:41, David Hildenbrand wrote: > We decided to always create the PCI host bridge, even if 'zpci' is not > enabled (due to migration compatibility). Couldn't we disable the host bridge for newer machine types, and just create it on the old ones for migration compatibility? > This however right now allows > to add zPCI/PCI devices to a VM although the guest will never actually see > them, confusing people that are using a simple CPU model that has no > 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > > Let's check for 'zpci' and at least print a warning that this will not > work as expected. We could also bail out, however that might break > existing QEMU commandlines. > > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > hw/s390x/s390-pci-bus.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > index b86a8bdcd4..e7d4f49611 100644 > --- a/hw/s390x/s390-pci-bus.c > +++ b/hw/s390x/s390-pci-bus.c > @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > { > S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > > + if (!s390_has_feat(S390_FEAT_ZPCI)) { > + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > + " The guest will not be able to see/use these devices."); > + } I think it would be better to bail out. The hotplug clearly can not work in this case, and the warn report might go unnoticed, so blocking the hotplug process is likely better to get the attention of the user. Thomas
On 22.01.19 10:50, Thomas Huth wrote: > On 2019-01-22 10:41, David Hildenbrand wrote: >> We decided to always create the PCI host bridge, even if 'zpci' is not >> enabled (due to migration compatibility). > > Couldn't we disable the host bridge for newer machine types, and just > create it on the old ones for migration compatibility? I think we can with a compat property. However I somewhat dislike that the error/warning will then be "no bus" vs. "zpci CPU feature not enabled". Somebody who has no idea about that will think he somehow has to create a PCI bus on the QEMU comandline. ... however > >> This however right now allows >> to add zPCI/PCI devices to a VM although the guest will never actually see >> them, confusing people that are using a simple CPU model that has no >> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >> >> Let's check for 'zpci' and at least print a warning that this will not >> work as expected. We could also bail out, however that might break >> existing QEMU commandlines. >> >> Signed-off-by: David Hildenbrand <david@redhat.com> >> --- >> hw/s390x/s390-pci-bus.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >> index b86a8bdcd4..e7d4f49611 100644 >> --- a/hw/s390x/s390-pci-bus.c >> +++ b/hw/s390x/s390-pci-bus.c >> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >> { >> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >> >> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >> + " The guest will not be able to see/use these devices."); >> + } > > I think it would be better to bail out. The hotplug clearly can not work > in this case, and the warn report might go unnoticed, so blocking the > hotplug process is likely better to get the attention of the user. ... we could also create the bus but bail out here in case the compat property strikes (a.k.a. new QEMO machine type). Thanks! > > Thomas >
On Tue, 22 Jan 2019 10:41:43 +0100 David Hildenbrand <david@redhat.com> wrote: > We decided to always create the PCI host bridge, even if 'zpci' is not > enabled (due to migration compatibility). This however right now allows > to add zPCI/PCI devices to a VM although the guest will never actually see > them, confusing people that are using a simple CPU model that has no > 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > > Let's check for 'zpci' and at least print a warning that this will not > work as expected. We could also bail out, however that might break > existing QEMU commandlines. > > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > hw/s390x/s390-pci-bus.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > index b86a8bdcd4..e7d4f49611 100644 > --- a/hw/s390x/s390-pci-bus.c > +++ b/hw/s390x/s390-pci-bus.c > @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > { > S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > > + if (!s390_has_feat(S390_FEAT_ZPCI)) { > + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > + " The guest will not be able to see/use these devices."); > + } > + > if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { > PCIDevice *pdev = PCI_DEVICE(dev); > That's hotplug only, isn't it? IIRC coldplugging already fails?
On 22.01.19 13:44, Cornelia Huck wrote: > On Tue, 22 Jan 2019 10:41:43 +0100 > David Hildenbrand <david@redhat.com> wrote: > >> We decided to always create the PCI host bridge, even if 'zpci' is not >> enabled (due to migration compatibility). This however right now allows >> to add zPCI/PCI devices to a VM although the guest will never actually see >> them, confusing people that are using a simple CPU model that has no >> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >> >> Let's check for 'zpci' and at least print a warning that this will not >> work as expected. We could also bail out, however that might break >> existing QEMU commandlines. >> >> Signed-off-by: David Hildenbrand <david@redhat.com> >> --- >> hw/s390x/s390-pci-bus.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >> index b86a8bdcd4..e7d4f49611 100644 >> --- a/hw/s390x/s390-pci-bus.c >> +++ b/hw/s390x/s390-pci-bus.c >> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >> { >> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >> >> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >> + " The guest will not be able to see/use these devices."); >> + } >> + >> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >> PCIDevice *pdev = PCI_DEVICE(dev); >> > > That's hotplug only, isn't it? IIRC coldplugging already fails? > No, applies also to coldplugging.
On Tue, 22 Jan 2019 11:06:46 +0100 David Hildenbrand <david@redhat.com> wrote: > On 22.01.19 10:50, Thomas Huth wrote: > > On 2019-01-22 10:41, David Hildenbrand wrote: > >> We decided to always create the PCI host bridge, even if 'zpci' is not > >> enabled (due to migration compatibility). > > > > Couldn't we disable the host bridge for newer machine types, and just > > create it on the old ones for migration compatibility? I very dimly remember some problems with that approach. > > I think we can with a compat property. However I somewhat dislike that > the error/warning will then be "no bus" vs. "zpci CPU feature not > enabled". Somebody who has no idea about that will think he somehow has > to create a PCI bus on the QEMU comandline. Agreed, "zpci cpu feature not enabled" gives a much better clue. > > ... however > > > > >> This however right now allows > >> to add zPCI/PCI devices to a VM although the guest will never actually see > >> them, confusing people that are using a simple CPU model that has no > >> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > >> > >> Let's check for 'zpci' and at least print a warning that this will not > >> work as expected. We could also bail out, however that might break > >> existing QEMU commandlines. > >> > >> Signed-off-by: David Hildenbrand <david@redhat.com> > >> --- > >> hw/s390x/s390-pci-bus.c | 5 +++++ > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > >> index b86a8bdcd4..e7d4f49611 100644 > >> --- a/hw/s390x/s390-pci-bus.c > >> +++ b/hw/s390x/s390-pci-bus.c > >> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > >> { > >> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > >> > >> + if (!s390_has_feat(S390_FEAT_ZPCI)) { > >> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > >> + " The guest will not be able to see/use these devices."); > >> + } > > > > I think it would be better to bail out. The hotplug clearly can not work > > in this case, and the warn report might go unnoticed, so blocking the > > hotplug process is likely better to get the attention of the user. > > ... we could also create the bus but bail out here in case the compat > property strikes (a.k.a. new QEMO machine type). Now you confused me... why should failing be based on a compat property?
On 22.01.19 14:13, Cornelia Huck wrote: > On Tue, 22 Jan 2019 11:06:46 +0100 > David Hildenbrand <david@redhat.com> wrote: > >> On 22.01.19 10:50, Thomas Huth wrote: >>> On 2019-01-22 10:41, David Hildenbrand wrote: >>>> We decided to always create the PCI host bridge, even if 'zpci' is not >>>> enabled (due to migration compatibility). >>> >>> Couldn't we disable the host bridge for newer machine types, and just >>> create it on the old ones for migration compatibility? > > I very dimly remember some problems with that approach. > >> >> I think we can with a compat property. However I somewhat dislike that >> the error/warning will then be "no bus" vs. "zpci CPU feature not >> enabled". Somebody who has no idea about that will think he somehow has >> to create a PCI bus on the QEMU comandline. > > Agreed, "zpci cpu feature not enabled" gives a much better clue. > >> >> ... however >> >>> >>>> This however right now allows >>>> to add zPCI/PCI devices to a VM although the guest will never actually see >>>> them, confusing people that are using a simple CPU model that has no >>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>>> >>>> Let's check for 'zpci' and at least print a warning that this will not >>>> work as expected. We could also bail out, however that might break >>>> existing QEMU commandlines. >>>> >>>> Signed-off-by: David Hildenbrand <david@redhat.com> >>>> --- >>>> hw/s390x/s390-pci-bus.c | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>>> index b86a8bdcd4..e7d4f49611 100644 >>>> --- a/hw/s390x/s390-pci-bus.c >>>> +++ b/hw/s390x/s390-pci-bus.c >>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>>> { >>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>>> >>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>>> + " The guest will not be able to see/use these devices."); >>>> + } >>> >>> I think it would be better to bail out. The hotplug clearly can not work >>> in this case, and the warn report might go unnoticed, so blocking the >>> hotplug process is likely better to get the attention of the user. >> >> ... we could also create the bus but bail out here in case the compat >> property strikes (a.k.a. new QEMO machine type). > > Now you confused me... why should failing be based on a compat property? > Otherwise, a QEMU comandline that used to work (which could be created by libvirt) would now fail. Are we ok with that?
On Tue, 22 Jan 2019 14:20:27 +0100 David Hildenbrand <david@redhat.com> wrote: > On 22.01.19 14:13, Cornelia Huck wrote: > > On Tue, 22 Jan 2019 11:06:46 +0100 > > David Hildenbrand <david@redhat.com> wrote: > > > >> On 22.01.19 10:50, Thomas Huth wrote: > >>> On 2019-01-22 10:41, David Hildenbrand wrote: > >>>> We decided to always create the PCI host bridge, even if 'zpci' is not > >>>> enabled (due to migration compatibility). > >>> > >>> Couldn't we disable the host bridge for newer machine types, and just > >>> create it on the old ones for migration compatibility? > > > > I very dimly remember some problems with that approach. > > > >> > >> I think we can with a compat property. However I somewhat dislike that > >> the error/warning will then be "no bus" vs. "zpci CPU feature not > >> enabled". Somebody who has no idea about that will think he somehow has > >> to create a PCI bus on the QEMU comandline. > > > > Agreed, "zpci cpu feature not enabled" gives a much better clue. > > > >> > >> ... however > >> > >>> > >>>> This however right now allows > >>>> to add zPCI/PCI devices to a VM although the guest will never actually see > >>>> them, confusing people that are using a simple CPU model that has no > >>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > >>>> > >>>> Let's check for 'zpci' and at least print a warning that this will not > >>>> work as expected. We could also bail out, however that might break > >>>> existing QEMU commandlines. > >>>> > >>>> Signed-off-by: David Hildenbrand <david@redhat.com> > >>>> --- > >>>> hw/s390x/s390-pci-bus.c | 5 +++++ > >>>> 1 file changed, 5 insertions(+) > >>>> > >>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > >>>> index b86a8bdcd4..e7d4f49611 100644 > >>>> --- a/hw/s390x/s390-pci-bus.c > >>>> +++ b/hw/s390x/s390-pci-bus.c > >>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > >>>> { > >>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > >>>> > >>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { > >>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > >>>> + " The guest will not be able to see/use these devices."); > >>>> + } > >>> > >>> I think it would be better to bail out. The hotplug clearly can not work > >>> in this case, and the warn report might go unnoticed, so blocking the > >>> hotplug process is likely better to get the attention of the user. > >> > >> ... we could also create the bus but bail out here in case the compat > >> property strikes (a.k.a. new QEMO machine type). > > > > Now you confused me... why should failing be based on a compat property? > > > > Otherwise, a QEMU comandline that used to work (which could be created > by libvirt) would now fail. Are we ok with that? > I think we should not fail at all in that case, then. Or only for hotplug, not for coldplug.
On 22.01.19 14:23, Cornelia Huck wrote: > On Tue, 22 Jan 2019 14:20:27 +0100 > David Hildenbrand <david@redhat.com> wrote: > >> On 22.01.19 14:13, Cornelia Huck wrote: >>> On Tue, 22 Jan 2019 11:06:46 +0100 >>> David Hildenbrand <david@redhat.com> wrote: >>> >>>> On 22.01.19 10:50, Thomas Huth wrote: >>>>> On 2019-01-22 10:41, David Hildenbrand wrote: >>>>>> We decided to always create the PCI host bridge, even if 'zpci' is not >>>>>> enabled (due to migration compatibility). >>>>> >>>>> Couldn't we disable the host bridge for newer machine types, and just >>>>> create it on the old ones for migration compatibility? >>> >>> I very dimly remember some problems with that approach. >>> >>>> >>>> I think we can with a compat property. However I somewhat dislike that >>>> the error/warning will then be "no bus" vs. "zpci CPU feature not >>>> enabled". Somebody who has no idea about that will think he somehow has >>>> to create a PCI bus on the QEMU comandline. >>> >>> Agreed, "zpci cpu feature not enabled" gives a much better clue. >>> >>>> >>>> ... however >>>> >>>>> >>>>>> This however right now allows >>>>>> to add zPCI/PCI devices to a VM although the guest will never actually see >>>>>> them, confusing people that are using a simple CPU model that has no >>>>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>>>>> >>>>>> Let's check for 'zpci' and at least print a warning that this will not >>>>>> work as expected. We could also bail out, however that might break >>>>>> existing QEMU commandlines. >>>>>> >>>>>> Signed-off-by: David Hildenbrand <david@redhat.com> >>>>>> --- >>>>>> hw/s390x/s390-pci-bus.c | 5 +++++ >>>>>> 1 file changed, 5 insertions(+) >>>>>> >>>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>>>>> index b86a8bdcd4..e7d4f49611 100644 >>>>>> --- a/hw/s390x/s390-pci-bus.c >>>>>> +++ b/hw/s390x/s390-pci-bus.c >>>>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>>>>> { >>>>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>>>>> >>>>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>>>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>>>>> + " The guest will not be able to see/use these devices."); >>>>>> + } >>>>> >>>>> I think it would be better to bail out. The hotplug clearly can not work >>>>> in this case, and the warn report might go unnoticed, so blocking the >>>>> hotplug process is likely better to get the attention of the user. >>>> >>>> ... we could also create the bus but bail out here in case the compat >>>> property strikes (a.k.a. new QEMO machine type). >>> >>> Now you confused me... why should failing be based on a compat property? >>> >> >> Otherwise, a QEMU comandline that used to work (which could be created >> by libvirt) would now fail. Are we ok with that? >> > > I think we should not fail at all in that case, then. Or only for > hotplug, not for coldplug. > We could fail on hotplug and warn on coldplug. This would keep existing setups running.
On Tue, 22 Jan 2019 14:25:07 +0100 David Hildenbrand <david@redhat.com> wrote: > On 22.01.19 14:23, Cornelia Huck wrote: > > On Tue, 22 Jan 2019 14:20:27 +0100 > > David Hildenbrand <david@redhat.com> wrote: > > > >> On 22.01.19 14:13, Cornelia Huck wrote: > >>> On Tue, 22 Jan 2019 11:06:46 +0100 > >>> David Hildenbrand <david@redhat.com> wrote: > >>> > >>>> On 22.01.19 10:50, Thomas Huth wrote: > >>>>> On 2019-01-22 10:41, David Hildenbrand wrote: > >>>>>> We decided to always create the PCI host bridge, even if 'zpci' is not > >>>>>> enabled (due to migration compatibility). > >>>>> > >>>>> Couldn't we disable the host bridge for newer machine types, and just > >>>>> create it on the old ones for migration compatibility? > >>> > >>> I very dimly remember some problems with that approach. > >>> > >>>> > >>>> I think we can with a compat property. However I somewhat dislike that > >>>> the error/warning will then be "no bus" vs. "zpci CPU feature not > >>>> enabled". Somebody who has no idea about that will think he somehow has > >>>> to create a PCI bus on the QEMU comandline. > >>> > >>> Agreed, "zpci cpu feature not enabled" gives a much better clue. > >>> > >>>> > >>>> ... however > >>>> > >>>>> > >>>>>> This however right now allows > >>>>>> to add zPCI/PCI devices to a VM although the guest will never actually see > >>>>>> them, confusing people that are using a simple CPU model that has no > >>>>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > >>>>>> > >>>>>> Let's check for 'zpci' and at least print a warning that this will not > >>>>>> work as expected. We could also bail out, however that might break > >>>>>> existing QEMU commandlines. > >>>>>> > >>>>>> Signed-off-by: David Hildenbrand <david@redhat.com> > >>>>>> --- > >>>>>> hw/s390x/s390-pci-bus.c | 5 +++++ > >>>>>> 1 file changed, 5 insertions(+) > >>>>>> > >>>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > >>>>>> index b86a8bdcd4..e7d4f49611 100644 > >>>>>> --- a/hw/s390x/s390-pci-bus.c > >>>>>> +++ b/hw/s390x/s390-pci-bus.c > >>>>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > >>>>>> { > >>>>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > >>>>>> > >>>>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { > >>>>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > >>>>>> + " The guest will not be able to see/use these devices."); > >>>>>> + } > >>>>> > >>>>> I think it would be better to bail out. The hotplug clearly can not work > >>>>> in this case, and the warn report might go unnoticed, so blocking the > >>>>> hotplug process is likely better to get the attention of the user. > >>>> > >>>> ... we could also create the bus but bail out here in case the compat > >>>> property strikes (a.k.a. new QEMO machine type). > >>> > >>> Now you confused me... why should failing be based on a compat property? > >>> > >> > >> Otherwise, a QEMU comandline that used to work (which could be created > >> by libvirt) would now fail. Are we ok with that? > >> > > > > I think we should not fail at all in that case, then. Or only for > > hotplug, not for coldplug. > > > > We could fail on hotplug and warn on coldplug. This would keep existing > setups running. > Ok with me.
On 22.01.2019 13:52, David Hildenbrand wrote: > On 22.01.19 13:44, Cornelia Huck wrote: >> On Tue, 22 Jan 2019 10:41:43 +0100 >> David Hildenbrand <david@redhat.com> wrote: >> >>> We decided to always create the PCI host bridge, even if 'zpci' is not >>> enabled (due to migration compatibility). This however right now allows >>> to add zPCI/PCI devices to a VM although the guest will never actually see >>> them, confusing people that are using a simple CPU model that has no >>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>> >>> Let's check for 'zpci' and at least print a warning that this will not >>> work as expected. We could also bail out, however that might break >>> existing QEMU commandlines. >>> >>> Signed-off-by: David Hildenbrand <david@redhat.com> >>> --- >>> hw/s390x/s390-pci-bus.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>> index b86a8bdcd4..e7d4f49611 100644 >>> --- a/hw/s390x/s390-pci-bus.c >>> +++ b/hw/s390x/s390-pci-bus.c >>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>> { >>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>> >>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>> + " The guest will not be able to see/use these devices."); >>> + } >>> + >>> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >>> PCIDevice *pdev = PCI_DEVICE(dev); >>> >> >> That's hotplug only, isn't it? IIRC coldplugging already fails? >> > > No, applies also to coldplugging. Back then we made this a conscious decision, because removing the bridge triggered a lot of issues regarding migration. And the current behaviour actually is a good match to the real hardware, there are PCI devices in the system that can not be used by guests. I understand that this is kind of surprising, so I am fine with the warn_report but I do not want to have a hard error right now.
On 22.01.19 16:03, Christian Borntraeger wrote: > > > On 22.01.2019 13:52, David Hildenbrand wrote: >> On 22.01.19 13:44, Cornelia Huck wrote: >>> On Tue, 22 Jan 2019 10:41:43 +0100 >>> David Hildenbrand <david@redhat.com> wrote: >>> >>>> We decided to always create the PCI host bridge, even if 'zpci' is not >>>> enabled (due to migration compatibility). This however right now allows >>>> to add zPCI/PCI devices to a VM although the guest will never actually see >>>> them, confusing people that are using a simple CPU model that has no >>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>>> >>>> Let's check for 'zpci' and at least print a warning that this will not >>>> work as expected. We could also bail out, however that might break >>>> existing QEMU commandlines. >>>> >>>> Signed-off-by: David Hildenbrand <david@redhat.com> >>>> --- >>>> hw/s390x/s390-pci-bus.c | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>>> index b86a8bdcd4..e7d4f49611 100644 >>>> --- a/hw/s390x/s390-pci-bus.c >>>> +++ b/hw/s390x/s390-pci-bus.c >>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>>> { >>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>>> >>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>>> + " The guest will not be able to see/use these devices."); >>>> + } >>>> + >>>> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >>>> PCIDevice *pdev = PCI_DEVICE(dev); >>>> >>> >>> That's hotplug only, isn't it? IIRC coldplugging already fails? >>> >> >> No, applies also to coldplugging. > > Back then we made this a conscious decision, because removing the bridge triggered a > lot of issues regarding migration. And the current behaviour actually is a good > match to the real hardware, there are PCI devices in the system that can not be used > by guests. I understand that this is kind of surprising, so I am fine with the warn_report > but I do not want to have a hard error right now. > So you agree to this patch, unmodified, correct? Thanks!
On 2019-01-22 16:11, David Hildenbrand wrote: > On 22.01.19 16:03, Christian Borntraeger wrote: >> >> >> On 22.01.2019 13:52, David Hildenbrand wrote: >>> On 22.01.19 13:44, Cornelia Huck wrote: >>>> On Tue, 22 Jan 2019 10:41:43 +0100 >>>> David Hildenbrand <david@redhat.com> wrote: >>>> >>>>> We decided to always create the PCI host bridge, even if 'zpci' is not >>>>> enabled (due to migration compatibility). This however right now allows >>>>> to add zPCI/PCI devices to a VM although the guest will never actually see >>>>> them, confusing people that are using a simple CPU model that has no >>>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>>>> >>>>> Let's check for 'zpci' and at least print a warning that this will not >>>>> work as expected. We could also bail out, however that might break >>>>> existing QEMU commandlines. >>>>> >>>>> Signed-off-by: David Hildenbrand <david@redhat.com> >>>>> --- >>>>> hw/s390x/s390-pci-bus.c | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>>> >>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>>>> index b86a8bdcd4..e7d4f49611 100644 >>>>> --- a/hw/s390x/s390-pci-bus.c >>>>> +++ b/hw/s390x/s390-pci-bus.c >>>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>>>> { >>>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>>>> >>>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>>>> + " The guest will not be able to see/use these devices."); >>>>> + } >>>>> + >>>>> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >>>>> PCIDevice *pdev = PCI_DEVICE(dev); >>>>> >>>> >>>> That's hotplug only, isn't it? IIRC coldplugging already fails? >>>> >>> >>> No, applies also to coldplugging. >> >> Back then we made this a conscious decision, because removing the bridge triggered a >> lot of issues regarding migration. And the current behaviour actually is a good >> match to the real hardware, there are PCI devices in the system that can not be used >> by guests. I understand that this is kind of surprising, so I am fine with the warn_report >> but I do not want to have a hard error right now. > > So you agree to this patch, unmodified, correct? Thanks! FWIW, it's fine for me: Reviewed-by: Thomas Huth <thuth@redhat.com>
On Tue, 22 Jan 2019 10:41:43 +0100 David Hildenbrand <david@redhat.com> wrote: > We decided to always create the PCI host bridge, even if 'zpci' is not > enabled (due to migration compatibility). This however right now allows > to add zPCI/PCI devices to a VM although the guest will never actually see > them, confusing people that are using a simple CPU model that has no > 'zpci' enabled - "Why isn't this working" (David Hildenbrand) > > Let's check for 'zpci' and at least print a warning that this will not > work as expected. We could also bail out, however that might break > existing QEMU commandlines. > > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > hw/s390x/s390-pci-bus.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > index b86a8bdcd4..e7d4f49611 100644 > --- a/hw/s390x/s390-pci-bus.c > +++ b/hw/s390x/s390-pci-bus.c > @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, > { > S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); > > + if (!s390_has_feat(S390_FEAT_ZPCI)) { > + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." > + " The guest will not be able to see/use these devices."); > + } > + > if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { > PCIDevice *pdev = PCI_DEVICE(dev); > So, it seems that the consensus was that this patch is fine in its current shape, right? If so, can I please get an ack from the zpci maintainer so I can queue it?
On 22.01.2019 16:11, David Hildenbrand wrote: > On 22.01.19 16:03, Christian Borntraeger wrote: >> >> >> On 22.01.2019 13:52, David Hildenbrand wrote: >>> On 22.01.19 13:44, Cornelia Huck wrote: >>>> On Tue, 22 Jan 2019 10:41:43 +0100 >>>> David Hildenbrand <david@redhat.com> wrote: >>>> >>>>> We decided to always create the PCI host bridge, even if 'zpci' is not >>>>> enabled (due to migration compatibility). This however right now allows >>>>> to add zPCI/PCI devices to a VM although the guest will never actually see >>>>> them, confusing people that are using a simple CPU model that has no >>>>> 'zpci' enabled - "Why isn't this working" (David Hildenbrand) >>>>> >>>>> Let's check for 'zpci' and at least print a warning that this will not >>>>> work as expected. We could also bail out, however that might break >>>>> existing QEMU commandlines. >>>>> >>>>> Signed-off-by: David Hildenbrand <david@redhat.com> >>>>> --- >>>>> hw/s390x/s390-pci-bus.c | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>>> >>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>>>> index b86a8bdcd4..e7d4f49611 100644 >>>>> --- a/hw/s390x/s390-pci-bus.c >>>>> +++ b/hw/s390x/s390-pci-bus.c >>>>> @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, >>>>> { >>>>> S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); >>>>> >>>>> + if (!s390_has_feat(S390_FEAT_ZPCI)) { >>>>> + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." >>>>> + " The guest will not be able to see/use these devices."); >>>>> + } >>>>> + >>>>> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >>>>> PCIDevice *pdev = PCI_DEVICE(dev); >>>>> >>>> >>>> That's hotplug only, isn't it? IIRC coldplugging already fails? >>>> >>> >>> No, applies also to coldplugging. >> >> Back then we made this a conscious decision, because removing the bridge triggered a >> lot of issues regarding migration. And the current behaviour actually is a good >> match to the real hardware, there are PCI devices in the system that can not be used >> by guests. I understand that this is kind of surprising, so I am fine with the warn_report >> but I do not want to have a hard error right now. >> > > So you agree to this patch, unmodified, correct? Thanks! Sorry, somehow lost this mail. Yes.
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index b86a8bdcd4..e7d4f49611 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -863,6 +863,11 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); + if (!s390_has_feat(S390_FEAT_ZPCI)) { + warn_report("Adding PCI or zPCI devices without the 'zpci' CPU feature." + " The guest will not be able to see/use these devices."); + } + if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { PCIDevice *pdev = PCI_DEVICE(dev);
We decided to always create the PCI host bridge, even if 'zpci' is not enabled (due to migration compatibility). This however right now allows to add zPCI/PCI devices to a VM although the guest will never actually see them, confusing people that are using a simple CPU model that has no 'zpci' enabled - "Why isn't this working" (David Hildenbrand) Let's check for 'zpci' and at least print a warning that this will not work as expected. We could also bail out, however that might break existing QEMU commandlines. Signed-off-by: David Hildenbrand <david@redhat.com> --- hw/s390x/s390-pci-bus.c | 5 +++++ 1 file changed, 5 insertions(+)