Re: [PATCH RFC v2] Add SUPPORT.md

[George Dunlap <george.dunlap@citrix.com>]

On 09/12/2017 11:39 AM, Roger Pau Monné wrote:
> On Mon, Sep 11, 2017 at 06:01:59PM +0100, George Dunlap wrote:
>> +## Toolstack
>> +
>> +### xl
>> +
>> +    Status: Supported
>> +
>> +### Direct-boot kernel image format
>> +
>> +    Supported, x86: bzImage
> 
> ELF
> 
>> +    Supported, ARM32: zImage
>> +    Supported, ARM64: Image
>> +
>> +Format which the toolstack accept for direct-boot kernels
> 
> IMHO it would be good to provide references to the specs, for ELF that
> should be:
> 
> http://refspecs.linuxbase.org/elf/elf.pdf

I'm having trouble evaluating these to recommendations because I don't
really know what the point of this section is.  Who wants this
information and why?

I think most end-users will want to build a Linux / whatever binary.
From that perspective, "bzImage" is probably the thing people want to
know about.  If you're doing unikernels or rolling your own custom
system somehow, knowing that it's ELF is probably more useful.

>> +### Qemu based disk backend (qdisk) for xl
>> +
>> +    Status: Supported
>> +
>> +### Open vSwitch integration for xl
>> +
>> +    Status: Supported
> 
> Status, Linux: Supported
> 
> I haven't played with vswitch on FreeBSD at all.

Ack

>> +### systemd support for xl
>> +
>> +    Status: Supported
>> +
>> +### JSON output support for xl
>> +
>> +    Status: Experimental
>> +
>> +Output of information in machine-parseable JSON format
>> +
>> +### AHCI support for xl
>> +
>> +    Status, x86: Supported
>> +
>> +### ACPI guest
>> +
>> +    Status, x86 HVM: Supported
>> +    Status, ARM: Tech Preview
> 
> status, x86 PVH: Tech preview

Is the interface and functionality mostly stable?  Or are the interfaces
likely to change / people using it likely to have crashes?

>> +### PVUSB support for xl
>> +
>> +    Status: Supported
>> +
>> +### HVM USB passthrough for xl
>> +
>> +    Status, x86: Supported
>> +
>> +### QEMU backend hotplugging for xl
>> +
>> +    Status: Supported
> 
> What's this exactly? Is it referring to hot-adding PV disk and nics?
> If so it shouldn't specifically reference xl, the same can be done
> with blkback or netback for example.

I think it means, xl knows how to hotplug QEMU backends.  There was a
time when I think this wasn't true.


>> +## Scalability
>> +
>> +### 1GB/2MB super page support
>> +
>> +    Status: Supported
> 
> This needs something like:
> 
> Status, x86 HVM/PVH: Supported

Sounds good -- I'll have a line for ARM as well.

> IIRC on ARM page sizes are different (64K?)
> 
>> +
>> +### x86/PV-on-HVM
>> +
>> +    Status: Supported
>> +
>> +This is a useful label for a set of hypervisor features
>> +which add paravirtualized functionality to HVM guests 
>> +for improved performance and scalability.  
>> +This includes exposing event channels to HVM guests.
>> +
>> +### x86/Deliver events to PVHVM guests using Xen event channels
>> +
>> +    Status: Supported
> 
> I think this should be labeled as "x86/HVM deliver guest events using
> event channels", and the x86/PV-on-HVM section removed.

Actually, I think 'PVHVM' should be the feature and this one should be
removed.


>> +### Blkfront
>> +
>> +    Status, Linux: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, Windows: Supported
> 
> Status, NetBSD: Supported, Security support external

Ack


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

Ack

> 
>> +
>> +### Xen PV keyboard
>> +
>> +    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]
>> +
>> +### Xen PVUSB protocol
>> +
>> +    Status, Linux: Supported
>> +
>> +### Xen PV SCSI protocol
>> +
>> +    Status, Linux: Supported, with caveats
> 
> Should both of the above items be labeled with frontend/backend?

Done.

> And do we really need the 'Xen' prefix in all the items? Seems quite
> redundant.

Let me think about that.

>> +
>> +NB that while the pvSCSU frontend is in Linux and tested regularly,
>> +there is currently no xl support.
>> +
>> +### Xen TPMfront
> 
> PV TPM frotnend

Ack

>> +### PVCalls frontend
>> +
>> +    Status, Linux: Tech Preview
>> +
>> +Guest-side driver capable of making pv system calls
> 
> Didn't we merge the backend, but not the frontend?

No idea

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

Ack

> 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
> 
> Status, NetBSD (xennetback): Supported
> 
> Both FreeBSD & NetBSD: security support external.

Ack

> 
>> +
>> +Host-side implementations of Xen PV network protocol
>> +
>> +### Xen Framebuffer
>> +
>> +    Status, Linux: Supported
> 
> Frontend?

>> +    Status, QEMU: Supported
> 
> Backend?
> 
> I don't recall Linux having a backend for the pv fb.

And it's hard to see how a Linux backend for pv FB would work in
practice; this is probably a mistake (maybe a c&p error).  I'll remove it.

>> +
>> +Host-side implementaiton of the Xen PV framebuffer protocol
>> +
>> +### Xen Console (xenconsoled)
> 
> Console backend
> 
>> +
>> +    Status: Supported
>> +
>> +Host-side implementation of the Xen PV console protocol
>> +
>> +### Xen PV keyboard
> 
> PV keyboard backend
> 
>> +
>> +    Status, QEMU: Supported
>> +
>> +Host-side implementation fo the Xen PV keyboard protocol
>> +
>> +### Xen PV USB
> 
> PV USB Backend
> 
>> +
>> +    Status, Linux: Experimental
> 
> ? The backend is in QEMU.

Juergen also has patches for a backend in Linux.

>> +### Online resize of virtual disks
>> +
>> +    Status: Supported
> 
> I would remove this.

I agree it probably doesn't belong here.

It might be useful to have a list of stuff like this as a prompt for
writing tests.  (Although perhaps good coverage support would be better.)


>> +### x86/HVM iPXE
>> +
>> +    Status: Supported, with caveats
>> +
>> +Booting a guest via PXE.
>> +PXE inherently places full trust of the guest in the network,
>> +and so should only be used
>> +when the guest network is under the same administrative control
>> +as the guest itself.
>> +
>> +### x86/HVM BIOS
>> +
>> +    Status: Supported
>> +
>> +Booting a guest via guest BIOS firmware
>> +
>> +### x86/HVM EFI
>> +
>> +	Status: Supported
>> +
>> +Booting a guest via guest EFI firmware
> 
> Maybe this is too generic? We certainly don't support ROMBIOS with
> qemu-trad, or SeaBIOS with qemu-upstream.

You mean we don't support SeaBIOS w/ qemu-trad or ROMBIOS with
qemu-upstream?

That probably doesn't matter so much, as SeaBIOS / ROMBIOS is mostly an
internal implementation detail.  But do we support booting EFI with
qemu-traditional?  If not, then you can't (for instance) boot an EFI
guest with stubdomains.

But then that opens up another factor in the matrix we need to track. :-/

>> +### ARM/ACPI (host)
>> +
>> +    Status: Experimental
> 
> "ACPI host" (since we already have "ACPI guest" above).

Yeah, I actually moved this to a separate "host hardware support" section.

> Status, ARM: experimental
> Status, x86 PV: supported
> Status, x86 PVH: experimental

Oh, this is for PV and PVH dom0.  I'll add a note to that effect.

Actually, how much of this is Xen support vs dom0 OS support?  Does this
need to be specified Linux / FreeBSD /&c?

 -George

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