I think the code is fine, I'm however having trouble parsing the commit message: "Guests on someone else's hardware may disable this, but for one's own hardware this is valuable.", could you please reword to something easier to parse? What do you mean with 'someone else's hardware'?

If someone has FreeBSD on a server where Domain 0 does not belong to them, then it could be undesirable to treat the Xen console as secure. Running FreeBSD as a DomU on one's own server, almost certainly you want the console considered secure.

I'll try to come up with better language.

In D29873#671117, @ehem_freebsd_m5p.com wrote:

If someone has FreeBSD on a server where Domain 0 does not belong to them, then it could be undesirable to treat the Xen console as secure. Running FreeBSD as a DomU on one's own server, almost certainly you want the console considered secure.

I'll try to come up with better language.

But the same would then apply to for example the disk backends, or the nics. you wouldn't trust them unless you also control the backends, which is not the common case I think.

If you don't trust dom0 then setting the console as secure or insecure won't make a difference, because dom0 is already capable of accessing your whole memory, or likely providing you with bogus disk or network data. That might change in the future but it's not the current model: a domU cannot protect itself against a malicious dom0.

Think about this, should D29873 add the Xen virtual console device to the sbin/init/ttys.* files for all architectures? This would keep these files consistent and at least one other architecture is looking at potential Xen support. My only question would be the treatment of x86. As of FreeBSD 12, the Xen code was using the emulated serial port as console instead of the ring. Should the ring device be added for x86 even though it currently isn't used?

In D29873#675124, @ehem_freebsd_m5p.com wrote:

Think about this, should D29873 add the Xen virtual console device to the sbin/init/ttys.* files for all architectures? This would keep these files consistent and at least one other architecture is looking at potential Xen support. My only question would be the treatment of x86. As of FreeBSD 12, the Xen code was using the emulated serial port as console instead of the ring. Should the ring device be added for x86 even though it currently isn't used?

The PV console (ring device) is used in PVH mode, see: https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-host-xen where it's noted that you need to modify /etc/ttys to add it. I think it would be fine to add for amd64 also at least. For other architectures I'm not so sure, the driver is not even built there so it makes little sense to add this to /etc/ttys. It might confuse people into thinking the architecture has Xen support.

In D29873#675154, @royger wrote:

In D29873#675124, @ehem_freebsd_m5p.com wrote:

Think about this, should D29873 add the Xen virtual console device to the sbin/init/ttys.* files for all architectures? This would keep these files consistent and at least one other architecture is looking at potential Xen support. My only question would be the treatment of x86. As of FreeBSD 12, the Xen code was using the emulated serial port as console instead of the ring. Should the ring device be added for x86 even though it currently isn't used?

The PV console (ring device) is used in PVH mode, see: https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-host-xen where it's noted that you need to modify /etc/ttys to add it. I think it would be fine to add for amd64 also at least. For other architectures I'm not so sure, the driver is not even built there so it makes little sense to add this to /etc/ttys. It might confuse people into thinking the architecture has Xen support.

The only reason to maybe add it is that our ttys are the same everywhere and we'd like to go to 1 ttys since the need to have it be radically different has passed away.

In D29873#675696, @imp wrote:

The only reason to maybe add it is that our ttys are the same everywhere and we'd like to go to 1 ttys since the need to have it be radically different has passed away.

Given this, I'm kind of tempted to pull the trigger and merge to a single file at the same time as adding the Xen console device.

In D29873#679072, @ehem_freebsd_m5p.com wrote:

In D29873#675696, @imp wrote:

The only reason to maybe add it is that our ttys are the same everywhere and we'd like to go to 1 ttys since the need to have it be radically different has passed away.

Given this, I'm kind of tempted to pull the trigger and merge to a single file at the same time as adding the Xen console device.

Seems fine, but please do it as two separate commits - one first to merge all files, and another one on top to add the Xen console.

Thanks for taking care of this!

One item of concern, is the placement of xc0 in the right spot in the list; should it be lower? Very much is not a serial port.