In D28264#632203, @debdrup wrote:

In D28264#632202, @jrtc27 wrote:

Don't know if I'm supposed to be able to push with a Reviewed by: + Approved by: debdrup, or if something just hates me, but I get "FATAL: VREF/APPROVERS-CHECK/doc: helper program exit status 65280", so could you please commit this for me?

This puzzled me, too, until I realized that it's past 02:00 UTC, which means the doc repo is read-only in preparation for the move to Hugo/AsciiDoctor, in accordance with Message-ID: <CAFwocyM9gA1iO2isXcDZTKRssF7xCbr=-iT8fPOsP_3Ctvf6tQ@mail.gmail.com>.

Admittedly, the error message is less than perfect.

Don't know if I'm supposed to be able to push with a Reviewed by: + Approved by: debdrup, or if something just hates me, but I get "FATAL: VREF/APPROVERS-CHECK/doc: helper program exit status 65280", so could you please commit this for me?

Fix unintended whitespace diff

The documentation for these says "When set to a nonempty string", and the GNU world does the same (e.g. see LD_TRACE_LOADED_OBJECTS=1 /bin/echo on a GNU/Linux system), so the strcmp shouldn't be added.

@gnn You're currently a blocking reviewer on this

So one question is: how far makes sense to take this? Should rtld always read the ABI-specific libmap+hints and search in lib32/lib64? Only handling the ABI-specific environment variables is inconsistent.

In D28054#629246, @mhorne wrote:

Looking at other implementations, I believe oldfp should be updated on each loop iteration.

Otherwise, the change seems correct to me, assuming the discussed issues will be addressed separately. I'd like to see the build fix committed soon.

In D28091#629163, @andrew wrote:

We could split out the -NODEBUG options to std.nodebug then include that from both here and GENERIC-NODEBUG

Rebasing this on top of D28073 would help to reduce the diff (provided you're still happy with the concept, but if so it'd be good to land the cleanup first IMO before all the new code comes in).

Hm, my instinct would be to make it include GENERIC-MMCCAM instead and then turn of debugging, especially given the name.

Ok, so *without* this patch I see a fatal page fault for a small integer address, but *with* this patch I see it attempting (but failing due to the buggy dtrace_fuword64 implementation) to read from a sensible address:

In D28054#627282, @kp wrote:

In D28054#627186, @jrtc27 wrote:

What's 0xffffffc0d282d870? My guess is it's dtrace_fuword64_nocheck;

That appears to be the case, yes. dtrace.ko is loaded at 0xffffffc0d2808000, dtrace_fuword64_nocheck is 0x25870 into the module, so that's at 0xFFFFFFC0D282D870.

Rebased on top of D28073

In D28054#627033, @kp wrote:

That at the very least fixes the build error, so on those grounds alone we should commit this.

However, I do see a panic with dtrace -n 'syscall:freebsd:write:entry { ustack(); }'. I've not yet dug into it to see if it's a direct result of this. I also see that stack() doesn't appear to work and I'm pretty sure that it used to.

root@pkgbuilder:~ # dtrace -n 'syscall:freebsd:write:entry { ustack(); }' &
[1] 718
root@pkgbuilder:~ # dtrace: description 'syscall:freebsd:write:entry ' matched 1 probe
t[0] == 0x0000000000000007
t[1] == 0xffffffc0d282e4bc
t[2] == 0x000000000000000a
t[3] == 0xffffffc0002ccb52
t[4] == 0x0000000040941600
t[5] == 0xfffffffffffffe93
t[6] == 0x0a3d70a3d70a3d71
s[0] == 0x0000000000000013
s[1] == 0x0000000000000011
s[2] == 0xffffffc0d2a00018
s[3] == 0x0000000000000014
s[4] == 0x0000000000000011
s[5] == 0x0000000000000001
s[6] == 0xffffffc0d2807000
s[7] == 0x0000000000000001
s[8] == 0x0000004000000001
s[9] == 0x0000000040242566
s[10] == 0xffffffc0d2a00020
s[11] == 0xffffffd13ccff600
a[0] == 0x0000000000000009
a[1] == 0xffffffc0d2807000
a[2] == 0xffffffc0764a0c50
a[3] == 0x0000000000000000
a[4] == 0xffffffc0d2807000
a[5] == 0x0000000000004ed6
a[6] == 0xffffffd003fac000
a[7] == 0xffffffc0d2a00000
ra == 0xffffffc0d2816fba
sp == 0xffffffc0764a0830
gp == 0x0000000000000001
tp == 0x0000000000000000
sepc == 0xffffffc0d282d870
sstatus == 0x0000000000004100
panic: Fatal page fault at 0xffffffc0d282d870: 0x00000000000009
cpuid = 0
time = 1610206153
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_fetch_ksymtab() at db_fetch_ksymtab+0x170
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x144
panic() at panic+0x26
do_trap_supervisor() at do_trap_supervisor+0x504
do_trap_supervisor() at do_trap_supervisor+0x64
cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x68
--- exception 13, tval = 0x9
KDB: enter: panic
[ thread pid 710 tid 100047 ]
Stopped at      kdb_enter+0x4c: sd      zero,0(a0)
db>

In D28058#627077, @imp wrote:

Does this survive universe? mips has no virtualization support at all, last I checked... A quick peek at virtio suggests that it's entirely platform neutral...

In D28054#626850, @mjg wrote:

Drop me from 'reported by'.

I have no basis to comment on the patch.

In D28026#626528, @markj wrote:

though FAR is not saved in the trapframe so we cannot print it

I think we at least print it before calling panic() when it makes sense to do so, so this doesn't seem like a problem.

In D28031#626514, @bryanv wrote:

In D28031#626513, @jrtc27 wrote:

In D28031#626500, @bryanv wrote:

In D28031#626487, @jrtc27 wrote:

<snip>

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

I think it is useful that a transport driver has been attached. Also my recollection when I original did it this way for PCI, is that this is needed for if the device (network, block, etc) module is later loaded. In the ensuing decade, devctl has appeared, but for driver development it is nice to just be able to load/unload the module for hack/test/hack.

Oh I didn't mean if a driver wasn't available, I meant if the device ID is 0. If it's non-zero but no driver's available that would still attach ready for if the driver gets loaded later, either automatically by devd or manually by the user.

ENXIO is fine for MMIO DeviceId of 0x0. Currently the MMIO driver fails to conform to section 4.2.3.1.1 w.r.t. to this.

In D28031#626500, @bryanv wrote:

In D28031#626487, @jrtc27 wrote:

For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:

root@:/ # devinfo
nexus0
  acpi0
    cpu0
    uart0
    virtio0
    virtio1
    virtio2
    virtio3
    virtio4
    virtio5
    virtio6
    virtio7
    virtio8
    virtio9
    virtio10
    virtio11
    virtio12
    virtio13
    virtio14
    virtio15
    virtio16
    virtio17
    virtio18
    virtio19
    virtio20
    virtio21
    virtio22
    virtio23
    virtio24
    virtio25
    virtio26
    virtio27
    virtio28
    virtio29
    virtio30
    virtio31
    pcib0
      pci0
        hostb0
        virtio32
          vtblk0
        virtio33
          vtnet0
        virtio34
    pci_link0
    pci_link1
    pci_link2
    pci_link3
    acpi_sysresource0
    acpi_button0
    psci0
    gic0
    generic_timer0
  cryptosoft0
  efirtc0
root@:/ # devinfo -p vtblk0
vtblk0 virtio32 pci0 pcib0 acpi0 nexus0
root@:/ # devinfo -p vtblk0 -v
vtblk0 pnpinfo vendor=0x00001af4 device=0x1001 subvendor=0x1af4 device_type=0x00000002
 virtio32 pnpinfo vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 class=0x010000 at slot=1 function=0 dbsf=pci0:0:1:0
 pci0
 pcib0 pnpinfo _HID=PNP0A08 _UID=0 _CID=PNP0A03 at handle=\_SB_.PCI0
 acpi0
 nexus0 pnpinfo nexus

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

I think it is useful that a transport driver has been attached. Also my recollection when I original did it this way for PCI, is that this is needed for if the device (network, block, etc) module is later loaded. In the ensuing decade, devctl has appeared, but for driver development it is nice to just be able to load/unload the module for hack/test/hack.

For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:

In D28031#626481, @bryanv wrote:

This would change the device names in places like devinfo, devctl, vmstat, etc, correct?

@bryanv Does this seem sensible to you? It's a cleanup/simplification I've been meaning to do for a while as the current situation is a bit silly, unless there's a reason you can think of why this is a bad idea?

\o/

@grehan Thanks :)

In D27855#622543, @bryanv wrote:

In D27855#622509, @jrtc27 wrote:

In D27855#622508, @bryanv wrote:

In D27855#622493, @jrtc27 wrote:

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

It is so wrong and incomplete that I have zero interest in trying to sort out the merge conflicts in the patches series I have for V1 support. This is so far away from _some_ V1 support that it is effectively _none_. Fix TinyEMU: it would appear it otherwise supports legacy but has a bug that requires VIRTIO_F_VERSION_1 to be negotiated.

That is grossly incorrect. There are a couple of deficiencies, and as I just said, everything I did is required for V1.

No, it is not just "a couple". I would advise you to read the VirtIO V1 spec. Or look at D27856 that starts to add V1 support. The OASIS TC did not spend years to develop a V1 specification that just ... negotiates VIRTIO_F_VERSION_1 on top of legacy VirtIO. Doing so here is so far from any V1 support that it is wrong pointless.

In D27855#622508, @bryanv wrote:

In D27855#622493, @jrtc27 wrote:

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

It is so wrong and incomplete that I have zero interest in trying to sort out the merge conflicts in the patches series I have for V1 support. This is so far away from _some_ V1 support that it is effectively _none_. Fix TinyEMU: it would appear it otherwise supports legacy but has a bug that requires VIRTIO_F_VERSION_1 to be negotiated.

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

In D27699#619276, @emaste wrote:

LGTM. I wonder why we ended up with these - in the case of itimerspec, sigevent etc. were the structs identical?

In D27669#618631, @kevans wrote:

In D27669#618626, @jrtc27 wrote:

Or just remove it and the ioctl given it's never used in the base system (and if it's always been broken can never have been used by anyone outside the base system either)?

It seems a little more difficult to assert that efi_get_table() couldn't have been used outside of the base system; this KPI has existed for four years and a caller could have easily mapped or had mapped the appropriate physical range to use it, no?

Or just remove it and the ioctl given it's never used in the base system (and if it's always been broken can never have been used by anyone outside the base system either)?

I believe the ioctl is the only consumer of this function though, and all others use the contrib efi version of the function?

Hm, on reflection, this doesn't quite do what it claims. Many of the arguments to this function come from fsbtodb and there are lots of daddr_t's floating around. Unless you want to purge all of them from existence (which is notionally wrong as they _are_ block numbers) I'd suggest leaving just the cast and dropping the rest of the diff.