Re: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86

From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: StefanoStabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@arm.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	xen-devel@lists.xenproject.org,
	AnthonyPerard <anthony.perard@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86
Date: Thu, 23 Nov 2017 17:02:09 +0000	[thread overview]
Message-ID: <6a3dd05e-1390-1c38-a7cd-c7706cbaf610@citrix.com> (raw)
In-Reply-To: <5A16B82902000078001914E1@prv-mh.provo.novell.com>

On 11/23/2017 10:59 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> Mostly PV protocols.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with a couple of remarks.
> 
>> @@ -223,6 +227,152 @@ 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
> 
> With "guest side" here, ...
> 
>> +### Blkfront
>> +
>> +    Status, Linux: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, OpenBSD: 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)
> 
> ... is "(frontend)" here (also on entries further down) really useful?
> Same for "host side" and "(backend)" then further down.

These were specifically requested, because the frontend and backend
entries end up looking very similar, and it's difficult to tell which
section you're in.

> Also would it perhaps make sense to sort multiple OS entries by
> some criteria (name, support status, ...)? Just like we ask that
> new source files have #include-s sorted, this helps reduce patch
> conflicts when otherwise everyone adds to the end of such lists.

Probably, yes.  I generally tried to rank them in order of {Linux, qemu,
*BSD, Windows}, on the grounds that Linux and QEMU are generally
developed by the "core" team (and have the most testing and attention),
and we should favor fellow open-source project (like the BSDs) over
proprietary systems (i.e., Windows).  But I don't seem to have been very
consistent in that.

>> +### 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.
> 
> Perhaps a copy-and-paste mistake saying "backend" here?

Good catch, thanks.

>> +### PV Framebuffer (backend)
>> +
>> +    Status, QEMU: Supported
>> +
>> +Host-side implementaiton of the Xen PV framebuffer protocol
> 
> implementation

Ack

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel