Re: Xen article for the FreeBSD Journal

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Nov 14, 2024 at 05:30:07PM -0800, Stefano Stabellini wrote:
> Hi Roger,
> 
> The article is very well written and I really enjoyed reading it. Well
> done! I have a couple of minor suggestions, feel free to take them or
> ignore them as you see fit.
> 
> 
> I would remove the sentence "PVH mode however requires modifications in
> the guest OS kernel so it's aware it's running under Xen and some
> devices are not available." I am not sure whether that's really true.
> Within AMD, we have added HPET emulation (optionally) to PVH, with that
> I think an unmodified guest could run as PVH.

I guess it depends on the guest.  For FreeBSD IIRC we would also need
an emulated PIT, as both the bootloader and the early kernel start
make use of it as a time counter.

I've adjusted this to use might:

"PVH mode however might require modifications in the guest OS..."

> 
> In the embedded section just before 'dom0less/hyperlaunch,' it would be
> beneficial to highlight the importance of real-time requirements. The
> vast majority of embedded deployments rely on low and deterministic
> interrupt latency to meet real-time needs. Significant efforts have been
> put into Xen to ensure interrupt latency remains both low and
> deterministic, even in the presence of cache pressure caused by noisy
> neighbors. Notably, the cache coloring patch series, now at version 9,
> has demonstrated excellent results in mitigating cache interference and
> maintaining deterministic latency at 2.5 microseconds.

I've added the following bullet point ahead of the
dom0less/hyperlaunch one:

 * Deterministic interrupt latency: significant efforts have been put into Xen
   to ensure interrupt latency remains both low and deterministic, even in the
   presence of cache pressure caused by noisy neighbors.  There's a patch
   series currently in review that adds cache coloring support to Xen.

> 
> This sentence: "There's an ongoing effort in Xen upstream to add PCI
> passthrough support for PVH dom0, however that's still being worked on,
> and when finished will require changes to FreeBSD for the feature to be
> usable." Why do you think there will be work required in FreeBSD? With
> vPCI, my expectation is that no work is required in FreeBSD (if the
> domUs are also PVH).

Oh, I was thinking about using current QEMU PCI-passthrough code in a
PVH dom0, and the work being done by AMD to support that mode.  That
will require changes in FreeBSD to implement something similar to
pciback, so that devices can be assigned to it, and device reset can
be performed.  Additionally changes to libxl will also be required
because all the code that deals with PCI devices is based on sysfs and
that's specific to Linux.

> 
> The sentence: "There are ongoing changes to the VirtIO specification to
> use grants instead of guest memory addresses as the basis for memory
> sharing between the VirtIO frontends and backends." The addition of
> grant table support to VirtIO is already completed. It is upstream in
> both Linux and QEMU. There is nothing else left to do there, and there
> is no need for a spec change. You can highlight that.

Oh, good to know.  I've replaced the current text with:

"Both Linux and QEMU currently support using VirtIO devices with grants
instead of guest memory addresses as the basis for memory sharing between the
VirtIO frontends and backends.  Such addition hasn't required a VirtIO
protocol change, since it's instead implemented as a new transport layer."

> At the same time
> it is true that there is still ongoing work to introduce changes to the
> VirtIO spec to make it safer and more secure (VirtIO-msg).
> 
> 
> Just before 'The future of Xen,' and following the discussion on MISRA
> C, it is worth noting that we have recently begun upstreaming safety
> requirements and assumptions of use. These can be found in
> docs/fusa/reqs. Safety requirements provide a detailed description of
> all the expected behaviors of the software (Xen), enabling independent
> testing and validation of these behaviors.

I've extended the paragraph with the following:

"Also as part of the Safety Certification initiative work as started
into adding safety requirements and assumptions of use.  Safety
requirements provide a detailed description of all the expected
behaviors of the software (Xen), enabling independent testing and
validation of these behaviors."

Thanks for all the useful feedback!

Roger.