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);
 
-- 
2.17.2

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
> 


-- 

Thanks,

David / dhildenb

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?

-- 

Thanks,

David / dhildenb

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.

-- 

Thanks,

David / dhildenb

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 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.

-- 

Thanks,

David / dhildenb

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!

-- 

Thanks,

David / dhildenb

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 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.

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?