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

[Yi Min Zhao]

在 2017/7/19 下午5:24, Cornelia Huck 写道:
> 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.
Yes, set summary and indicator bits. Related stuff is in flic, but not 
in zpci.