qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v2 4/9] s390x/pci: do not advertise pci on n


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH RFC v2 4/9] s390x/pci: do not advertise pci on non-pci builds
Date: Wed, 19 Jul 2017 11:24:30 +0200

On Wed, 19 Jul 2017 16:56:18 +0800
Yi Min Zhao <address@hidden> wrote:

> 在 2017/7/19 下午4:00, Cornelia Huck 写道:
> > On Tue, 18 Jul 2017 21:56:26 +0200
> > Christian Borntraeger <address@hidden> wrote:
> >  
> >> On 07/18/2017 04:24 PM, Cornelia Huck wrote:  
> >>> Only set the zpci and aen feature bits on builds that actually
> >>> support pci.
> >>>
> >>> Signed-off-by: Cornelia Huck <address@hidden>
> >>> ---
> >>>   target/s390x/kvm.c | 2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> >>> index 831492f9a2..880eccd58a 100644
> >>> --- a/target/s390x/kvm.c
> >>> +++ b/target/s390x/kvm.c
> >>> @@ -2685,8 +2685,10 @@ void kvm_s390_get_host_cpu_model(S390CPUModel 
> >>> *model, Error **errp)
> >>>       }
> >>>
> >>>       /* set zpci and aen facilities */
> >>> +#ifdef CONFIG_PCI
> >>>       set_bit(S390_FEAT_ZPCI, model->features);
> >>>       set_bit(S390_FEAT_ADAPTER_EVENT_NOTIFICATION, model->features);
> >>> +#endif
> >>>
> >>>       if (s390_known_cpu_type(cpu_type)) {
> >>>           /* we want the exact model, even if some features are missing */
> >>>      
> >> Not strictly necessary but do you also want to ifdef this
> >>
> >>   kvm_vm_enable_cap(s, KVM_CAP_S390_AIS, 0);
> >>
> >> call?
> >>
> >> If not you could actually even allow AEN but not PCI for !CONFIG_PCI.  
> > I'm a bit unsure about the relationship of ais and aen with pci. I
> > remember that only adapters for pci currently support suppression,
> > although it could spread to other adapter types in the future. Not sure
> > about aen.
> >
> > So I'd keep the ais enablement call, even though it won't have much of
> > an effect as no pci adapters will be registered.
> >
> > As I don't quite remember what aen governed, I need to rely on your
> > feedback here.
> >
> >  
> My understanding is that zpci replies on aen. But aen could exist 
> independently.
> After all, there is other device type using aen. I think only wrapping 
> zpci is
> enough.

Ah, was aen the indicator bits related support? If yes, I agree that we
should only turn off zpci.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]