diff mbox

[07/16] SUPPORT.md: Add virtual devices common to ARM and x86

Message ID 20171113154126.13038-7-george.dunlap@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

George Dunlap Nov. 13, 2017, 3:41 p.m. UTC
Mostly PV protocols.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
The xl side of this seems a bit incomplete: There are a number of
things supported but not mentioned (like networking, &c), and a number
of things not in xl (PV SCSI).  Couldn't find evidence of pvcall or pv
keyboard support.  Also we seem to be missing "PV channels" from this
list entirely

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Anthony Perard <anthony.perard@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 160 insertions(+)

Comments

Jan Beulich Nov. 21, 2017, 8:29 a.m. UTC | #1
>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
> +### PV USB support for xl
> +
> +    Status: Supported
> +
> +### PV 9pfs support for xl
> +
> +    Status: Tech Preview

Why are these two being called out, but xl support for other device
types isn't?

> +### QEMU backend hotplugging for xl
> +
> +    Status: Supported

Wouldn't this more appropriately be

### QEMU backend hotplugging

    Status, xl: Supported

?

> +## Virtual driver support, guest side
> +
> +### Blkfront
> +
> +    Status, Linux: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, Windows: Supported
> +
> +Guest-side driver capable of speaking the Xen PV block protocol
> +
> +### Netfront
> +
> +    Status, Linux: Supported
> +    States, Windows: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, OpenBSD: Supported, Security support external

Seeing the difference in OSes between the two (with the variance
increasing in entries further down) - what does the absence of an
OS on one list, but its presence on another mean? While not
impossible, I would find it surprising if e.g. OpenBSD had netfront
but not even a basic blkfront.

> +Guest-side driver capable of speaking the Xen PV networking protocol
> +
> +### PV Framebuffer (frontend)
> +
> +    Status, Linux (xen-fbfront): Supported
> +
> +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
> +
> +### PV Console (frontend)
> +
> +    Status, Linux (hvc_xen): Supported
> +    Status, Windows: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +
> +Guest-side driver capable of speaking the Xen PV console protocol
> +
> +### PV keyboard (frontend)
> +
> +    Status, Linux (xen-kbdfront): Supported
> +    Status, Windows: Supported
> +
> +Guest-side driver capable of speaking the Xen PV keyboard protocol

Are these three active/usable in guests regardless of whether the
guest is being run PV, PVH, or HVM? If not, wouldn't this need
spelling out?

> +## Virtual device support, host side
> +
> +### Blkback
> +
> +    Status, Linux (blkback): Supported

Strictly speaking, if the driver name is to be spelled out here in
the first place, it's xen-blkback here and ...

> +    Status, FreeBSD (blkback): Supported, Security support external
> +    Status, NetBSD (xbdback): Supported, security support external
> +    Status, QEMU (xen_disk): Supported
> +    Status, Blktap2: Deprecated
> +
> +Host-side implementations of the Xen PV block protocol
> +
> +### Netback
> +
> +    Status, Linux (netback): Supported

... xen-netback here for the upstream kernels.

> +### PV USB (backend)
> +
> +    Status, Linux: Experimental

What existing/upstream code does this refer to?

Jan
Paul Durrant Nov. 21, 2017, 9:19 a.m. UTC | #2
> -----Original Message-----
[snip]
> > +### PV keyboard (frontend)
> > +
> > +    Status, Linux (xen-kbdfront): Supported
> > +    Status, Windows: Supported
> > +
> > +Guest-side driver capable of speaking the Xen PV keyboard protocol
> 
> Are these three active/usable in guests regardless of whether the
> guest is being run PV, PVH, or HVM? If not, wouldn't this need
> spelling out?
> 

I believe the necessary patches to make the PV vkdb protocol usable independently of vfb are at least queued for upstream QEMU.

Stefano, am I correct?

Cheers,

  Paul
George Dunlap Nov. 21, 2017, 10:56 a.m. UTC | #3
On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
>> +### PV USB support for xl
>> +
>> +    Status: Supported
>> +
>> +### PV 9pfs support for xl
>> +
>> +    Status: Tech Preview
> 
> Why are these two being called out, but xl support for other device
> types isn't?

Do you see how big this document is? :-)  If you think something else
needs to be covered, don't ask why I didn't mention it, just say what
you think I missed.

> 
>> +### QEMU backend hotplugging for xl
>> +
>> +    Status: Supported
> 
> Wouldn't this more appropriately be
> 
> ### QEMU backend hotplugging
> 
>     Status, xl: Supported

Maybe -- let me think about it.

> 
> ?
> 
>> +## Virtual driver support, guest side
>> +
>> +### Blkfront
>> +
>> +    Status, Linux: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, Windows: Supported
>> +
>> +Guest-side driver capable of speaking the Xen PV block protocol
>> +
>> +### Netfront
>> +
>> +    Status, Linux: Supported
>> +    States, Windows: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, OpenBSD: Supported, Security support external
> 
> Seeing the difference in OSes between the two (with the variance
> increasing in entries further down) - what does the absence of an
> OS on one list, but its presence on another mean? While not
> impossible, I would find it surprising if e.g. OpenBSD had netfront
> but not even a basic blkfront.

Good catch.  Roger suggested that I add the OpenBSD Netfront; he's away
so I'll have to see if I can figure out if they have blkfront support or
not.

>> +Guest-side driver capable of speaking the Xen PV networking protocol
>> +
>> +### PV Framebuffer (frontend)
>> +
>> +    Status, Linux (xen-fbfront): Supported
>> +
>> +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
>> +
>> +### PV Console (frontend)
>> +
>> +    Status, Linux (hvc_xen): Supported
>> +    Status, Windows: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +
>> +Guest-side driver capable of speaking the Xen PV console protocol
>> +
>> +### PV keyboard (frontend)
>> +
>> +    Status, Linux (xen-kbdfront): Supported
>> +    Status, Windows: Supported
>> +
>> +Guest-side driver capable of speaking the Xen PV keyboard protocol
> 
> Are these three active/usable in guests regardless of whether the
> guest is being run PV, PVH, or HVM? If not, wouldn't this need
> spelling out?

In theory I think they could be used; I suspect it's just that they
aren't used.  Let me see if I can think of a way to concisely express that.

>> +## Virtual device support, host side
>> +
>> +### Blkback
>> +
>> +    Status, Linux (blkback): Supported
> 
> Strictly speaking, if the driver name is to be spelled out here in
> the first place, it's xen-blkback here and ...
> 
>> +    Status, FreeBSD (blkback): Supported, Security support external
>> +    Status, NetBSD (xbdback): Supported, security support external
>> +    Status, QEMU (xen_disk): Supported
>> +    Status, Blktap2: Deprecated
>> +
>> +Host-side implementations of the Xen PV block protocol
>> +
>> +### Netback
>> +
>> +    Status, Linux (netback): Supported
> 
> ... xen-netback here for the upstream kernels.

Ack.


>> +### PV USB (backend)
>> +
>> +    Status, Linux: Experimental
> 
> What existing/upstream code does this refer to?

I guess a bunch of patches posted to a mailing list?  Yeah, that's
probably something we should take out.

 -George
Jan Beulich Nov. 21, 2017, 11:41 a.m. UTC | #4
>>> On 21.11.17 at 11:56, <george.dunlap@citrix.com> wrote:
> On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
>>> +### PV USB support for xl
>>> +
>>> +    Status: Supported
>>> +
>>> +### PV 9pfs support for xl
>>> +
>>> +    Status: Tech Preview
>> 
>> Why are these two being called out, but xl support for other device
>> types isn't?
> 
> Do you see how big this document is? :-)  If you think something else
> needs to be covered, don't ask why I didn't mention it, just say what
> you think I missed.

Well, (not very) implicitly here: The same for all other PV protocols.

Jan
George Dunlap Nov. 21, 2017, 5:20 p.m. UTC | #5
On 11/21/2017 11:41 AM, Jan Beulich wrote:
>>>> On 21.11.17 at 11:56, <george.dunlap@citrix.com> wrote:
>> On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
>>>> +### PV USB support for xl
>>>> +
>>>> +    Status: Supported
>>>> +
>>>> +### PV 9pfs support for xl
>>>> +
>>>> +    Status: Tech Preview
>>>
>>> Why are these two being called out, but xl support for other device
>>> types isn't?
>>
>> Do you see how big this document is? :-)  If you think something else
>> needs to be covered, don't ask why I didn't mention it, just say what
>> you think I missed.
> 
> Well, (not very) implicitly here: The same for all other PV protocols.

Oh, I see -- you didn't read my comment below the `---` pointing this
out.  :-)

Yes, I wasn't quite sure what to do here.  We already list all the PV
protocols in at least 2 places (frontend and backend support); it seemed
a bit redundant to list them all again in xl and/or libxl support.

Except, of course, that there are a number of protocols *not* plumbed
through the toolstack yet -- PVSCSI being one example.

Any suggestions would be welcome.

 -George
George Dunlap Nov. 21, 2017, 5:35 p.m. UTC | #6
On 11/21/2017 08:29 AM, Jan Beulich wrote:
>> +### QEMU backend hotplugging for xl
>> +
>> +    Status: Supported
> 
> Wouldn't this more appropriately be
> 
> ### QEMU backend hotplugging
> 
>     Status, xl: Supported

You mean, for this whole section (i.e., everything here that says 'for
xl')?  If not, why this one in particular?

>> +## Virtual driver support, guest side
>> +
>> +### Blkfront
>> +
>> +    Status, Linux: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, Windows: Supported
>> +
>> +Guest-side driver capable of speaking the Xen PV block protocol
>> +
>> +### Netfront
>> +
>> +    Status, Linux: Supported
>> +    States, Windows: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, OpenBSD: Supported, Security support external
> 
> Seeing the difference in OSes between the two (with the variance
> increasing in entries further down) - what does the absence of an
> OS on one list, but its presence on another mean? While not
> impossible, I would find it surprising if e.g. OpenBSD had netfront
> but not even a basic blkfront.

Actually -- at least according to the paper presenting PV frontends for
OpenBSD in 2016 [1], they implemented xenstore and netfront frontends,
but not (at least at that point) a disk frontend.

However, blktfront does appear as a feature in OpenBSD 6.1, released in
April [2]; so I'll add that one in.  (Perhaps Roger hadn't heard that it
had been implemented.)

[1] https://www.openbsd.org/papers/asiabsdcon2016-xen-paper.pdf

[2] https://www.openbsd.org/61.html

 -George
Jan Beulich Nov. 22, 2017, 11:05 a.m. UTC | #7
>>> On 21.11.17 at 18:20, <george.dunlap@citrix.com> wrote:
> On 11/21/2017 11:41 AM, Jan Beulich wrote:
>>>>> On 21.11.17 at 11:56, <george.dunlap@citrix.com> wrote:
>>> On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
>>>>> +### PV USB support for xl
>>>>> +
>>>>> +    Status: Supported
>>>>> +
>>>>> +### PV 9pfs support for xl
>>>>> +
>>>>> +    Status: Tech Preview
>>>>
>>>> Why are these two being called out, but xl support for other device
>>>> types isn't?
>>>
>>> Do you see how big this document is? :-)  If you think something else
>>> needs to be covered, don't ask why I didn't mention it, just say what
>>> you think I missed.
>> 
>> Well, (not very) implicitly here: The same for all other PV protocols.
> 
> Oh, I see -- you didn't read my comment below the `---` pointing this
> out.  :-)

Oops, sorry.

> Yes, I wasn't quite sure what to do here.  We already list all the PV
> protocols in at least 2 places (frontend and backend support); it seemed
> a bit redundant to list them all again in xl and/or libxl support.
> 
> Except, of course, that there are a number of protocols *not* plumbed
> through the toolstack yet -- PVSCSI being one example.
> 
> Any suggestions would be welcome.

How about putting that as a note to the respective frontend /
backend entries? And then, wouldn't lack of xl support anyway
mean "experimental" at best?

Jan
Jan Beulich Nov. 22, 2017, 11:07 a.m. UTC | #8
>>> On 21.11.17 at 18:35, <george.dunlap@citrix.com> wrote:
> On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>> +### QEMU backend hotplugging for xl
>>> +
>>> +    Status: Supported
>> 
>> Wouldn't this more appropriately be
>> 
>> ### QEMU backend hotplugging
>> 
>>     Status, xl: Supported
> 
> You mean, for this whole section (i.e., everything here that says 'for
> xl')?  If not, why this one in particular?

Well, I had commented on the other two entries separately, and
from my other reply just sent it would follow that I'd rather see
those other two entries go away (information moved elsewhere).

Jan
George Dunlap Nov. 22, 2017, 4:16 p.m. UTC | #9
On 11/22/2017 11:05 AM, Jan Beulich wrote:
>>>> On 21.11.17 at 18:20, <george.dunlap@citrix.com> wrote:
>> On 11/21/2017 11:41 AM, Jan Beulich wrote:
>>>>>> On 21.11.17 at 11:56, <george.dunlap@citrix.com> wrote:
>>>> On 11/21/2017 08:29 AM, Jan Beulich wrote:
>>>>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
>>>>>> +### PV USB support for xl
>>>>>> +
>>>>>> +    Status: Supported
>>>>>> +
>>>>>> +### PV 9pfs support for xl
>>>>>> +
>>>>>> +    Status: Tech Preview
>>>>>
>>>>> Why are these two being called out, but xl support for other device
>>>>> types isn't?
>>>>
>>>> Do you see how big this document is? :-)  If you think something else
>>>> needs to be covered, don't ask why I didn't mention it, just say what
>>>> you think I missed.
>>>
>>> Well, (not very) implicitly here: The same for all other PV protocols.
>>
>> Oh, I see -- you didn't read my comment below the `---` pointing this
>> out.  :-)
> 
> Oops, sorry.
> 
>> Yes, I wasn't quite sure what to do here.  We already list all the PV
>> protocols in at least 2 places (frontend and backend support); it seemed
>> a bit redundant to list them all again in xl and/or libxl support.
>>
>> Except, of course, that there are a number of protocols *not* plumbed
>> through the toolstack yet -- PVSCSI being one example.
>>
>> Any suggestions would be welcome.
> 
> How about putting that as a note to the respective frontend /
> backend entries? And then, wouldn't lack of xl support anyway
> mean "experimental" at best?

Yes.

Since the toolstack mainly sets up the backend, I added a  note in the
'backend' section saying that unless otherwise noted, "Tech preview" and
"Supported" imply xl support for creating backends.

We might want to add in libvirt support enumeration at some point.

 -George
diff mbox

Patch

diff --git a/SUPPORT.md b/SUPPORT.md
index a8c56d13dd..20c58377a5 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -130,6 +130,22 @@  Output of information in machine-parseable JSON format
 
     Status: Supported
 
+### Qemu based disk backend (qdisk) for xl
+
+    Status: Supported
+
+### PV USB support for xl
+
+    Status: Supported
+
+### PV 9pfs support for xl
+
+    Status: Tech Preview
+
+### QEMU backend hotplugging for xl
+
+    Status: Supported
+
 ## Toolstack/3rd party
 
 ### libvirt driver for xl
@@ -216,6 +232,150 @@  which add paravirtualized functionality to HVM guests
 for improved performance and scalability.
 This includes exposing event channels to HVM guests.
 
+## Virtual driver support, guest side
+
+### Blkfront
+
+    Status, Linux: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+    Status, Windows: Supported
+
+Guest-side driver capable of speaking the Xen PV block protocol
+
+### Netfront
+
+    Status, Linux: Supported
+    States, Windows: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+    Status, OpenBSD: Supported, Security support external
+
+Guest-side driver capable of speaking the Xen PV networking protocol
+
+### PV Framebuffer (frontend)
+
+    Status, Linux (xen-fbfront): Supported
+
+Guest-side driver capable of speaking the Xen PV Framebuffer protocol
+
+### PV Console (frontend)
+
+    Status, Linux (hvc_xen): Supported
+    Status, Windows: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+
+Guest-side driver capable of speaking the Xen PV console protocol
+
+### PV keyboard (frontend)
+
+    Status, Linux (xen-kbdfront): Supported
+    Status, Windows: Supported
+
+Guest-side driver capable of speaking the Xen PV keyboard protocol
+
+[XXX 'Supported' here depends on the version we ship in 4.10 having some fixes]
+
+### PV USB (frontend)
+
+    Status, Linux: Supported
+
+### PV SCSI protocol (frontend)
+
+    Status, Linux: Supported, with caveats
+
+NB that while the PV SCSI backend is in Linux and tested regularly,
+there is currently no xl support.
+
+### PV TPM (frontend)
+
+    Status, Linux (xen-tpmfront): Tech Preview
+
+Guest-side driver capable of speaking the Xen PV TPM protocol
+
+### PV 9pfs frontend
+
+    Status, Linux: Tech Preview
+
+Guest-side driver capable of speaking the Xen 9pfs protocol
+
+### PVCalls (frontend)
+
+    Status, Linux: Tech Preview
+
+Guest-side driver capable of making pv system calls
+
+Note that there is currently no xl support for pvcalls.
+
+## Virtual device support, host side
+
+### Blkback
+
+    Status, Linux (blkback): Supported
+    Status, FreeBSD (blkback): Supported, Security support external
+    Status, NetBSD (xbdback): Supported, security support external
+    Status, QEMU (xen_disk): Supported
+    Status, Blktap2: Deprecated
+
+Host-side implementations of the Xen PV block protocol
+
+### Netback
+
+    Status, Linux (netback): Supported
+    Status, FreeBSD (netback): Supported, Security support external
+    Status, NetBSD (xennetback): Supported, Security support external
+
+Host-side implementations of Xen PV network protocol
+
+### PV Framebuffer (backend)
+
+    Status, QEMU: Supported
+
+Host-side implementaiton of the Xen PV framebuffer protocol
+
+### PV Console (xenconsoled)
+
+    Status: Supported
+
+Host-side implementation of the Xen PV console protocol
+
+### PV keyboard (backend)
+
+    Status, QEMU: Supported
+
+Host-side implementation fo the Xen PV keyboard protocol
+
+### PV USB (backend)
+
+    Status, Linux: Experimental
+    Status, QEMU: Supported
+
+Host-side implementation of the Xen PV USB protocol
+
+### PV SCSI protocol (backend)
+
+    Status, Linux: Supported, with caveats
+
+NB that while the PV SCSI backend is in Linux and tested regularly,
+there is currently no xl support.
+
+### PV TPM (backend)
+
+    Status: Tech Preview
+
+### PV 9pfs (backend)
+
+    Status, QEMU: Tech Preview
+
+### PVCalls (backend)
+
+    Status, Linux: Tech Preview
+
+### Online resize of virtual disks
+
+    Status: Supported
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.