- User Since
- May 9 2014, 10:54 PM (307 w, 3 d)
Sun, Mar 29
Sat, Mar 28
Fri, Mar 20
add GUID value for discovering SMBIOS tables in UEFI, which iirc would help our UEFI situation
Wed, Mar 18
Mon, Mar 16
So it will be a choice of a UEFI firmware that does VNC and passthru but no NVMe or one
that does VNC and NVMe, that will be confusing.
Sun, Mar 15
I'm assuming this is an illumos specific issue, but it might be worth to test this on FreeBSD too.
Mar 1 2020
Yamagi has mentioned some small optimizations that could be added to this (e.g. saving the TPR in the vcpu struct and only writing to the VMCS if there has been a change) but this can be done in future commits.
Feb 18 2020
Feb 13 2020
Is this good to go?
Feb 12 2020
Feb 10 2020
Feb 7 2020
Jan 29 2020
The alternative solution (the same used by QEMU) is to read the packet in a local bounce buffer (64KB), so that we figure out its actual length and then we call vq_getchain() the corrent number of times (e.g. just once for 1500 bytes packets). The cost for this solution is an additional packet copy, which is not good imho.
Jan 28 2020
I'd suggest going even further by not making it an option and fixing it as always on. There doesn't seem to be any reason to have it disabled.
Jan 17 2020
I think this change breaks x2apic mode (and Yamagi might have a patch for that) so I'd hold off committing for a bit.
Jan 15 2020
I don't understand how to parse that sentence (or how it would work). Is this just a function of our EFI stack being a borrowed blob from TianoCore EDK II?
Yeah, I first learned of this horror when an ACPICA update broke Bhyve because the syntax the compiler recognized for FADT or similar changed. It's... not as crazy as it might seem. It might be preferable if the compiler was linked in instead of system()'d, but whatever.
A note for future work: with Windows, the ACPI tables are generated from within UEFI. You would need either a tag on the UUID so EFI could search for it (like it does with the SMBIOS tables), or use the fw i/f to allow UEFI to query the address of the UUID. I can help with that.
Jan 7 2020
A worthwhile change.
Jun 13 2019
Jun 10 2018
May 23 2018
May 14 2018
Good to go with the name change.
May 4 2018
I checked with Leon and he thought this was fine. Will submit pending the copyright issue.
May 3 2018
May 2 2018
Update style as per jhb.
Yes, this code was submitted by Matt M.
bhyve passthru is currently restricted to the subset of devices that can support MSI/MSI-x so this doesn't come into play for older PCI devices.
Apr 30 2018
Apr 24 2018
Apr 21 2018
This looks fine, though I'm interested in the circumstances that this can happen - can module-load pre-empt an existing kernel thread that is in the midst of invltlb_glob() ?
Apr 15 2018
Apr 12 2018
I think this should be fine. Can always be tweaked later.
Apr 6 2018
Fine by me. Looking forward to using this :)
Mar 20 2018
Anything available I could use to test this on AMD ?
Mar 18 2018
Adding Tycho to this.
Needs capsicum patches or it won't work (testing was done with Capsicum disabled).
Mar 11 2018
Mar 7 2018
So a comment on this: in general, api's are not added to FreeBSD that don't have base-system clients that use them, or for a good reason. I think this falls into the latter but I'd like to cut it down a bit.
- can the get_unrestricted_guest() routine be removed ? There is an error return on the set, which seems like it can be used to determine if unrestricted mode is not available (e.g. that's how bhyve uses the ioctl).
- is there a need for vcpu_reset() ? The BSP should be initialized to power-on state.. That could be a bug in bhyve and better to have it fixed there.
so I do not see why running a bunch of tests would yield.
Mar 5 2018
You might have to explain further why you think you are exempt from having to demonstrate testing with this.
I'd like to see some guest test results (FreeBSD, Linux, Windows) for varying numbers of these, in particular, with sockets > 1, and comparing what Qemu shows for the same configuration.
Mar 4 2018
Mar 1 2018
Feb 25 2018
This is an excellent change :)
Feb 22 2018
You may be able to get away with just the "set" call. Given that all h/w that is supported by bhyve, with the exception of only Nehalem systems, support this, you may want to use just the error from the set call to handle this low-probability error.
Feb 21 2018
Feb 17 2018
Thanks for getting back to this Rod.
Feb 15 2018
Only minor issue I had was the trailing underscores in the inline routine name: wasn't too sure if that was idiomatic FreeBSD. Maybe "_int" ?
Feb 10 2018
Jan 26 2018
Update from Leon:
Jan 25 2018
Closing this revision - moving to D14022
Yep, that's correct. The code in the new review is based on this code so it's really a continuation of the effort.
Chuck - the review for this is now in D14022, where I believe your comments have already been addressed.
Some minor fixes from Leon, and an initial man page update.
Jan 23 2018
I don't think I'll be able to get the CR8 stuff done as quick as I'd hoped, so I think it's fine to go ahead with this as-is. In addition, both Andriy and Anish have reported that Windows guests come up fine so the issue may not be as big a deal as I'd previously thought.
I'll pull in the man page diff (maybe modified). Leon also sent me an update so I'll roll both in.
The updated version of this code is at https://reviews.freebsd.org/D14022
Jan 21 2018
Leon Dang has also been working on NVMe emulation, and his version works with Linux, Windows and UEFI boot. I'll post that code for review since it is a bit more recent and tested. In the meantime, that version can be seen at www.freebsd.org/~grehan/pci_nvme.c
Jan 17 2018
Jan 15 2018
Tested the SVM codepath with a Win10 guest on an AMD Sempron APU.
Add bhyve review group.
Dropping kern.hz to 50 on the Sempron seemed to show the problem a bit more: the 2nd phase of a Win10 install wasn't able to complete. With the diff, the install was able to complete. Subjectively things seemed quicker, particularly the disk-writing part of the install.
Jan 14 2018
Some more info on how timing-sensitive this is: the 10.3 install Ryzen insta-repro doesn't happen with a 4 vCPU guest on a 1.3Gzh Sempron 3850 APU, nor with 4/6/8 vCPU guests on an Opteron 6320 :( Also, Win10 Pro 2 vCPU guests install fine on both systems, where the Ryzen shows a lockup very quickly.
Jan 11 2018
The VIRQ injection doesn't cover all cases - it misses out the modification of the TPR register via CR8.
Jan 10 2018
CR8 write exits are required or the same situation will occur as with VIRQ - the update written to the V_TPR needs to be acted on immediately by the APIC emulation code since an interrupt that was blocked may need to be injected.
Jan 8 2018
Good to know that it fixes the issue on the Phenom. My Ryzen 1700 is pre-July17 so can't necessarily be trusted.
Also, I think CR8 write exits are needed to force re-evaluation of the TPR for the software APIC model.
I didn't have success with this on my Ryzen 1700, but it's also possibly buggy :( I'll try with an Opteron tomorrow.
Dec 21 2017
Dec 20 2017
This looks fine. I'll test on AMD. Some comments:
Dec 6 2017
Adding tychon@ as a subscriber: he's been doing some 9P work in recent times.
Nov 26 2017
Nov 9 2017
Thanks for this patch.