qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids


From: Cornelia Huck
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Tue, 28 Nov 2017 15:45:14 +0100

On Tue, 28 Nov 2017 15:17:49 +0100
Christian Borntraeger <address@hidden> wrote:

> On 11/28/2017 03:01 PM, Cornelia Huck wrote:
> > On Tue, 28 Nov 2017 14:25:08 +0100
> > Christian Borntraeger <address@hidden> wrote:

> >> What I want now is to enable vfio-ccw for libvirt and Linux guests and for 
> >> that
> >> we need to lift the restriction of having vfio not in FE.  
> > 
> > This, however, worries me. I don't really consider vfio-ccw ready for
> > prime time yet. We still need to figure out path handling at the very
> > least. And I'm still not sure that our non-handling of halt/clear won't
> > cause major issues with e.g. a storage server error recovery.
> > 
> > Can we flag vfio-ccw as experimental or such in libvirt?  
> 
> We should have flagged vfio-ccw experimental in QEMU then.
> e.g. by using x-vfio-ccw or whatever.I dont think we can do that
> after the facts.

Yes, we should have done that... can't fix that now, unfortunately.

> 
> I am not that deep into vfio-ccw, but I was under the impression that
> the missing features should not affect the vfio interface that is
> created by libvirt. After all this should just be a "-device vfio-ccw,....."
> statement and some setup steps beforehand (unbind + setup of vfio-ccw)

The halt/clear stuff is highly unlikely to influence the configuration
interface. I'm still not too clear about path handling, though. Will we
need different modes (hypervisor managed vs. full passthrough? probably
only passthrough)? What about pgid handling - do we need some kind of
pgid manager? (Keep in mind that you get to set the pgid once. This has
implications for e.g. reserve/release.)

Also, what about devices other than ECKD DASD? Has there been any
testing? Tapes should be interesting; the other interesting ccw devices
are QDIO-based and I'm not sure we want to spend anything on supporting
those.

The interface is probably fine, but I'd like to get an idea about the
path stuff (is the attachment spec that contains the pgid stuff
publicly available, btw.?)

> 
> If your concern is the serviceability I think it would be valid for a RHEL
> KVM to disable vfio-ccw in the kernel. Maybe we could even provide a config
> for QEMU?

It's fine just to turn off vfio-ccw in the kernel.

> PS: I learned from the PCI and CCW experience that I do not want
> to upstream kernel/qemu code unless I have a working libvirt code that
> shows that the thing will work.

Yes, I understand the wish to verify the interface, and I think it's a
good idea. What I'm worried about is that this might be the precursor
to a push to support it, and I don't think vfio-ccw is ready for that
yet.



reply via email to

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