Re: svn commit: r359950 - head/usr.sbin/bhyve
Thanks, Conrad! I'll test out the change tomorrow after the HardenedBSD auto-sync scripts run tonight. I'll report back tomorrow. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc On Sun, Apr 19, 2020 at 04:55:37PM -0700, Conrad Meyer wrote: > Committed in r360107, if you don't mind rebooting to try the patch. I > will work on the slightly more complicated additional steps mentioned > earlier, but those will take a little more time. > > Thanks again, > Conrad > > On Sun, Apr 19, 2020 at 4:50 PM Conrad Meyer wrote: > > > > https://reviews.freebsd.org/D24507 :-) > > > > On Sun, Apr 19, 2020 at 4:45 PM Peter Grehan wrote: > > > > > > > Unless there is an ABI problem, I think we should probably go > > > > ahead and bump VM_MAX_MEMMAPS > > > > > > That's a reasonable fix - double it (or more) until it's made dynamic. > > > The VGA code is another (future) client of this, and it would allow > > > other things like multiple frame buffers. > > > > > > later, > > > > > > Peter. signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
Committed in r360107, if you don't mind rebooting to try the patch. I will work on the slightly more complicated additional steps mentioned earlier, but those will take a little more time. Thanks again, Conrad On Sun, Apr 19, 2020 at 4:50 PM Conrad Meyer wrote: > > https://reviews.freebsd.org/D24507 :-) > > On Sun, Apr 19, 2020 at 4:45 PM Peter Grehan wrote: > > > > > Unless there is an ABI problem, I think we should probably go > > > ahead and bump VM_MAX_MEMMAPS > > > > That's a reasonable fix - double it (or more) until it's made dynamic. > > The VGA code is another (future) client of this, and it would allow > > other things like multiple frame buffers. > > > > later, > > > > Peter. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
https://reviews.freebsd.org/D24507 :-) On Sun, Apr 19, 2020 at 4:45 PM Peter Grehan wrote: > > > Unless there is an ABI problem, I think we should probably go > > ahead and bump VM_MAX_MEMMAPS > > That's a reasonable fix - double it (or more) until it's made dynamic. > The VGA code is another (future) client of this, and it would allow > other things like multiple frame buffers. > > later, > > Peter. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
Unless there is an ABI problem, I think we should probably go ahead and bump VM_MAX_MEMMAPS That's a reasonable fix - double it (or more) until it's made dynamic. The VGA code is another (future) client of this, and it would allow other things like multiple frame buffers. later, Peter. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
Thanks! I believe we're running into VM_MAX_MEMMAPS (4) due to: 1. Low memory (0 through PCI hole) 2. High memory (4GB+) 3. Framebuffer 4. VMgenid's segment 5. EFI firmware's segment As a temporary workaround, if you do not need any of: >3GB RAM, framebuffer, or EFI boot, turning off any one of these should free a segment and allow boot. Unless there is an ABI problem, I think we should probably go ahead and bump VM_MAX_MEMMAPS, or make it dynamically sized. And as a userspace workaround for the issue that doesn't require a reboot (or reload of vmm.ko), we could add a knob to bhyve(8) to disable vmgenid. Best, Conrad On Sun, Apr 19, 2020 at 4:14 PM Shawn Webb wrote: > > This is the full output from bhyve: > > fbuf frame buffer base: 0x69191a0 [sz 16777216] > bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device > bhyve: vmgenc_init: bootrom_alloc > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > On Sun, Apr 19, 2020 at 04:04:16PM -0700, Conrad Meyer wrote: > > Hey Shawn, > > > > I will take a look. Thanks for the report and especially the repro example. > > What sort of bad symptoms are you observing (or will it be super obvious > > when I try this)? > > > > Thanks, > > Conrad > > > > On Sun, Apr 19, 2020 at 15:53 Shawn Webb wrote: > > > > > On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > > > > Author: cem > > > > Date: Wed Apr 15 02:00:17 2020 > > > > New Revision: 359950 > > > > URL: https://svnweb.freebsd.org/changeset/base/359950 > > > > > > > > Log: > > > > bhyve(8): Add VM Generation Counter ACPI device > > > > > > > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > > > > Bhyve. The spec provides a randomly generated GUID (at bhyve start) > > > > in > > > > device memory, along with an ACPI device with _CID VM_Gen_Counter and > > > ADDR > > > > evaluating to a Package pointing at that GUID. > > > > > > > > A GPE is defined which Notifies the ACPI Device when the generation > > > changes > > > > (such as when a snapshot is rolled back). At this time, Bhyve does > > > > not > > > > support snapshotting, so the GPE is never actually raised. > > > > > > > > Suggested by: rpokala > > > > Discussed with: grehan > > > > Differential Revision: https://reviews.freebsd.org/D23165 > > > > > > > > Added: > > > > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > > > > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > > > > Modified: > > > > head/usr.sbin/bhyve/Makefile > > > > head/usr.sbin/bhyve/acpi.c > > > > head/usr.sbin/bhyve/acpi.h > > > > head/usr.sbin/bhyve/bhyverun.c > > > > head/usr.sbin/bhyve/pm.c > > > > > > Hey Conrad, > > > > > > Something about this commit broke bhyve in UEFI mode. Reverting this > > > specific change caused bhyve to work again. Here's a sample command: > > > > > > /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ > > > -c 4 \ > > > -m 16g \ > > > -H \ > > > -A \ > > > -P \ > > > -S \ > > > -g 0 \ > > > -s 0:0,hostbridge \ > > > -s 1:0,lpc \ > > > -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ > > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > > > -s 2:0,virtio-net,tap1 \ > > > -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 > > > \ > > > -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ > > > -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso > > > \ > > > hbsd-cdcfi-01 > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder / Security Engineer > > > HardenedBSD > > > > > > GPG Key ID: 0xFF2E67A277F8E1FA > > > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > > > > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
On Mon, Apr 20, 2020 at 02:32:23AM +0300, Yuri Pankov wrote: > Shawn Webb wrote: > > This is the full output from bhyve: > > > > fbuf frame buffer base: 0x69191a0 [sz 16777216] > > bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device > > bhyve: vmgenc_init: bootrom_alloc > > I wonder if it's coincidence, and you really didn't have 16G to wire at that > moment, and after reverting the commit it was there (reboot?) -- I was > getting the same error well before this change when I had almost all of the > memory eaten by ZFS ARC, I was looking at r359949 as possible candidate, but > limiting that memory hog did make the issue disappear. Good thought, but this was on a fresh reboot on my laptop with 64GB ECC RAM. At the time bhyve was started, I had 55GB memory free. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
Shawn Webb wrote: This is the full output from bhyve: fbuf frame buffer base: 0x69191a0 [sz 16777216] bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device bhyve: vmgenc_init: bootrom_alloc I wonder if it's coincidence, and you really didn't have 16G to wire at that moment, and after reverting the commit it was there (reboot?) -- I was getting the same error well before this change when I had almost all of the memory eaten by ZFS ARC, I was looking at r359949 as possible candidate, but limiting that memory hog did make the issue disappear. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
This is the full output from bhyve: fbuf frame buffer base: 0x69191a0 [sz 16777216] bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device bhyve: vmgenc_init: bootrom_alloc Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc On Sun, Apr 19, 2020 at 04:04:16PM -0700, Conrad Meyer wrote: > Hey Shawn, > > I will take a look. Thanks for the report and especially the repro example. > What sort of bad symptoms are you observing (or will it be super obvious > when I try this)? > > Thanks, > Conrad > > On Sun, Apr 19, 2020 at 15:53 Shawn Webb wrote: > > > On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > > > Author: cem > > > Date: Wed Apr 15 02:00:17 2020 > > > New Revision: 359950 > > > URL: https://svnweb.freebsd.org/changeset/base/359950 > > > > > > Log: > > > bhyve(8): Add VM Generation Counter ACPI device > > > > > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > > > Bhyve. The spec provides a randomly generated GUID (at bhyve start) in > > > device memory, along with an ACPI device with _CID VM_Gen_Counter and > > ADDR > > > evaluating to a Package pointing at that GUID. > > > > > > A GPE is defined which Notifies the ACPI Device when the generation > > changes > > > (such as when a snapshot is rolled back). At this time, Bhyve does not > > > support snapshotting, so the GPE is never actually raised. > > > > > > Suggested by: rpokala > > > Discussed with: grehan > > > Differential Revision: https://reviews.freebsd.org/D23165 > > > > > > Added: > > > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > > > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > > > Modified: > > > head/usr.sbin/bhyve/Makefile > > > head/usr.sbin/bhyve/acpi.c > > > head/usr.sbin/bhyve/acpi.h > > > head/usr.sbin/bhyve/bhyverun.c > > > head/usr.sbin/bhyve/pm.c > > > > Hey Conrad, > > > > Something about this commit broke bhyve in UEFI mode. Reverting this > > specific change caused bhyve to work again. Here's a sample command: > > > > /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ > > -c 4 \ > > -m 16g \ > > -H \ > > -A \ > > -P \ > > -S \ > > -g 0 \ > > -s 0:0,hostbridge \ > > -s 1:0,lpc \ > > -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > > -s 2:0,virtio-net,tap1 \ > > -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 \ > > -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ > > -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso \ > > hbsd-cdcfi-01 > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > GPG Key ID: 0xFF2E67A277F8E1FA > > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
Hey Shawn, I will take a look. Thanks for the report and especially the repro example. What sort of bad symptoms are you observing (or will it be super obvious when I try this)? Thanks, Conrad On Sun, Apr 19, 2020 at 15:53 Shawn Webb wrote: > On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > > Author: cem > > Date: Wed Apr 15 02:00:17 2020 > > New Revision: 359950 > > URL: https://svnweb.freebsd.org/changeset/base/359950 > > > > Log: > > bhyve(8): Add VM Generation Counter ACPI device > > > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > > Bhyve. The spec provides a randomly generated GUID (at bhyve start) in > > device memory, along with an ACPI device with _CID VM_Gen_Counter and > ADDR > > evaluating to a Package pointing at that GUID. > > > > A GPE is defined which Notifies the ACPI Device when the generation > changes > > (such as when a snapshot is rolled back). At this time, Bhyve does not > > support snapshotting, so the GPE is never actually raised. > > > > Suggested by: rpokala > > Discussed with: grehan > > Differential Revision: https://reviews.freebsd.org/D23165 > > > > Added: > > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > > Modified: > > head/usr.sbin/bhyve/Makefile > > head/usr.sbin/bhyve/acpi.c > > head/usr.sbin/bhyve/acpi.h > > head/usr.sbin/bhyve/bhyverun.c > > head/usr.sbin/bhyve/pm.c > > Hey Conrad, > > Something about this commit broke bhyve in UEFI mode. Reverting this > specific change caused bhyve to work again. Here's a sample command: > > /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ > -c 4 \ > -m 16g \ > -H \ > -A \ > -P \ > -S \ > -g 0 \ > -s 0:0,hostbridge \ > -s 1:0,lpc \ > -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > -s 2:0,virtio-net,tap1 \ > -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 \ > -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ > -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso \ > hbsd-cdcfi-01 > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359950 - head/usr.sbin/bhyve
On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > Author: cem > Date: Wed Apr 15 02:00:17 2020 > New Revision: 359950 > URL: https://svnweb.freebsd.org/changeset/base/359950 > > Log: > bhyve(8): Add VM Generation Counter ACPI device > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > Bhyve. The spec provides a randomly generated GUID (at bhyve start) in > device memory, along with an ACPI device with _CID VM_Gen_Counter and ADDR > evaluating to a Package pointing at that GUID. > > A GPE is defined which Notifies the ACPI Device when the generation changes > (such as when a snapshot is rolled back). At this time, Bhyve does not > support snapshotting, so the GPE is never actually raised. > > Suggested by: rpokala > Discussed with: grehan > Differential Revision: https://reviews.freebsd.org/D23165 > > Added: > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > Modified: > head/usr.sbin/bhyve/Makefile > head/usr.sbin/bhyve/acpi.c > head/usr.sbin/bhyve/acpi.h > head/usr.sbin/bhyve/bhyverun.c > head/usr.sbin/bhyve/pm.c Hey Conrad, Something about this commit broke bhyve in UEFI mode. Reverting this specific change caused bhyve to work again. Here's a sample command: /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ -c 4 \ -m 16g \ -H \ -A \ -P \ -S \ -g 0 \ -s 0:0,hostbridge \ -s 1:0,lpc \ -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -s 2:0,virtio-net,tap1 \ -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 \ -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso \ hbsd-cdcfi-01 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
svn commit: r359950 - head/usr.sbin/bhyve
Author: cem
Date: Wed Apr 15 02:00:17 2020
New Revision: 359950
URL: https://svnweb.freebsd.org/changeset/base/359950
Log:
bhyve(8): Add VM Generation Counter ACPI device
Add an implementatation of the 'Virtual Machine Generation ID' spec to
Bhyve. The spec provides a randomly generated GUID (at bhyve start) in
device memory, along with an ACPI device with _CID VM_Gen_Counter and ADDR
evaluating to a Package pointing at that GUID.
A GPE is defined which Notifies the ACPI Device when the generation changes
(such as when a snapshot is rolled back). At this time, Bhyve does not
support snapshotting, so the GPE is never actually raised.
Suggested by: rpokala
Discussed with: grehan
Differential Revision:https://reviews.freebsd.org/D23165
Added:
head/usr.sbin/bhyve/vmgenc.c (contents, props changed)
head/usr.sbin/bhyve/vmgenc.h (contents, props changed)
Modified:
head/usr.sbin/bhyve/Makefile
head/usr.sbin/bhyve/acpi.c
head/usr.sbin/bhyve/acpi.h
head/usr.sbin/bhyve/bhyverun.c
head/usr.sbin/bhyve/pm.c
Modified: head/usr.sbin/bhyve/Makefile
==
--- head/usr.sbin/bhyve/MakefileWed Apr 15 01:58:51 2020
(r359949)
+++ head/usr.sbin/bhyve/MakefileWed Apr 15 02:00:17 2020
(r359950)
@@ -67,6 +67,7 @@ SRCS= \
usb_mouse.c \
virtio.c\
vga.c \
+ vmgenc.c\
xmsr.c \
spinup_ap.c \
iov.c
Modified: head/usr.sbin/bhyve/acpi.c
==
--- head/usr.sbin/bhyve/acpi.c Wed Apr 15 01:58:51 2020(r359949)
+++ head/usr.sbin/bhyve/acpi.c Wed Apr 15 02:00:17 2020(r359950)
@@ -74,6 +74,7 @@ __FBSDID("$FreeBSD$");
#include "bhyverun.h"
#include "acpi.h"
#include "pci_emul.h"
+#include "vmgenc.h"
/*
* Define the base address of the ACPI tables, the sizes of some tables,
@@ -367,13 +368,13 @@ basl_fwrite_fadt(FILE *fp)
EFPRINTF(fp, "[0004]\t\tPM2 Control Block Address : \n");
EFPRINTF(fp, "[0004]\t\tPM Timer Block Address : %08X\n",
IO_PMTMR);
- EFPRINTF(fp, "[0004]\t\tGPE0 Block Address : \n");
+ EFPRINTF(fp, "[0004]\t\tGPE0 Block Address : %08X\n", IO_GPE0_BLK);
EFPRINTF(fp, "[0004]\t\tGPE1 Block Address : \n");
EFPRINTF(fp, "[0001]\t\tPM1 Event Block Length : 04\n");
EFPRINTF(fp, "[0001]\t\tPM1 Control Block Length : 02\n");
EFPRINTF(fp, "[0001]\t\tPM2 Control Block Length : 00\n");
EFPRINTF(fp, "[0001]\t\tPM Timer Block Length : 04\n");
- EFPRINTF(fp, "[0001]\t\tGPE0 Block Length : 00\n");
+ EFPRINTF(fp, "[0001]\t\tGPE0 Block Length : %02x\n", IO_GPE0_LEN);
EFPRINTF(fp, "[0001]\t\tGPE1 Block Length : 00\n");
EFPRINTF(fp, "[0001]\t\tGPE1 Base Offset : 00\n");
EFPRINTF(fp, "[0001]\t\t_CST Support : 00\n");
@@ -501,10 +502,10 @@ basl_fwrite_fadt(FILE *fp)
EFPRINTF(fp, "[0012]\t\tGPE0 Block : [Generic Address Structure]\n");
EFPRINTF(fp, "[0001]\t\tSpace ID : 01 [SystemIO]\n");
- EFPRINTF(fp, "[0001]\t\tBit Width : 00\n");
+ EFPRINTF(fp, "[0001]\t\tBit Width : %02x\n", IO_GPE0_LEN * 8);
EFPRINTF(fp, "[0001]\t\tBit Offset : 00\n");
EFPRINTF(fp, "[0001]\t\tEncoded Access Width : 01 [Byte Access:8]\n");
- EFPRINTF(fp, "[0008]\t\tAddress : \n");
+ EFPRINTF(fp, "[0008]\t\tAddress : %016X\n", IO_GPE0_BLK);
EFPRINTF(fp, "\n");
EFPRINTF(fp, "[0012]\t\tGPE1 Block : [Generic Address Structure]\n");
@@ -756,6 +757,9 @@ basl_fwrite_dsdt(FILE *fp)
dsdt_line(" })");
dsdt_line("}");
dsdt_line(" }");
+
+ vmgenc_write_dsdt();
+
dsdt_line("}");
if (dsdt_error != 0)
Modified: head/usr.sbin/bhyve/acpi.h
==
--- head/usr.sbin/bhyve/acpi.h Wed Apr 15 01:58:51 2020(r359949)
+++ head/usr.sbin/bhyve/acpi.h Wed Apr 15 02:00:17 2020(r359950)
@@ -42,9 +42,19 @@
#defineIO_PMTMR0x408 /* 4-byte i/o port for the
timer */
+#defineIO_GPE0_BLK 0x40c /* 2x 1-byte IO port for
GPE0_STS/EN */
+#defineIO_GPE0_LEN 0x2
+
+#defineIO_GPE0_STS IO_GPE0_BLK
+#defineIO_GPE0_EN (IO_GPE0_BLK + (IO_GPE0_LEN / 2))
+
+/* Allocated GPE bits. */
+#defineGPE_VMGENC 0
+
struct vmctx;
intacpi_build(struct vmctx *ctx, int ncpu);
+void acpi_raise_gpe(struct vmctx *ctx, unsigned bit);
void dsdt_line(const char *fmt, ...);
void dsdt_fixed_ioport(uint16_t iobase, uint16_t length);
void dsdt_fixed_irq(uint8_t irq);
Modified: head/usr.sbin/bhyve/bhyverun.c
