Re: Booting a disk image with GRUB in BHyve?
Hi Craig, (4) Tried vmrun.sh: vmrun.sh is FreeBSD-only. How can I boot something which uses GRUB bootloader in BHyve? There is a user-space port of grub2 that allows a number of Linux distros to boot (sysutils/grub2-bhyve). However, for Linux distros such as rhel/centos 6.* that use grub-1, it's somewhat of a manual process. Illumos/SmartOS is a different kettle of fish. It's grub-1, but the the o/s itself presents a number of issues that are still being worked through (BIOS calls, timer modes/calibration etc). later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Booting a disk image with GRUB in BHyve?
Hi, I tried the following: (1) Downloaded SmartOS USB image from: http://wiki.smartos.org/display/DOC/Download+SmartOS (2) Uncompressed the bz2 file. (3) Ran "file" on the binary: # file smartos-latest-USB.img smartos-latest-USB.img: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000, stage2 segment 0x200; partition 1: ID=0xc, starthead 1, startsector 63, 3903732 sectors, extended partition table (last)\011, code offset 0x48 (4) Tried vmrun.sh: sh /usr/share/examples/bhyve/vmrun.sh -d ./smartos-latest-USB.img -m 4G smartos_vm1 I got this error: = Launching virtual machine "smartos_vm1" ... Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@pcbsd-4708, Mon Oct 14 14:36:53 PDT 2013) \ can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK How can I boot something which uses GRUB bootloader in BHyve? Thanks. -- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: 11.0-CURRENT panic while running a bhyve instance
Works for me (I'm at r259742), no panic. Thanks! -- Markiyan. 2013/12/23 Neel Natu : > Hi Markiyan, > > Fixed in r259737: > http://svnweb.freebsd.org/changeset/base/259737 > > best > Neel > > On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir > wrote: >> 2013/12/13 John Baldwin : >>> On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. >>> >>> The mailing lists strips attachments, can you post it at a URL? >>> >> >> Shared here: >> >> https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing >> >> -- >> Markiyan. >> -- Markiyan -- Forwarded message -- From: Markiyan Kushnir Date: 2013/12/13 Subject: To: freebsd-curr...@freebsd.org, freebsd-virtualization@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >>> >>> -- >>> John Baldwin >> ___ >> freebsd-curr...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: [PATCH] Support for S5 (soft power off) in bhyve
On Monday, December 23, 2013 5:01:45 pm Neel Natu wrote:
> Hi John,
>
> This looks good - thanks for adding this support!
>
> I noticed that the RESET_REGISTER is not being advertised in the FACP
> flags field. So, perhaps the access to 0xCF9 that you saw during
> testing was triggered by cpu_reset_real() as opposed to AcpiReset()?
Yeah, that might explain why I had to comment out the 0x64 check in
bhyverun.c directly as AcpiReset() should take precedence before
cpu_reset_real() is invoked. I'll retest that tomorrow to make sure I have
the FACP correct.
> best
> Neel
>
> On Mon, Dec 23, 2013 at 11:43 AM, John Baldwin wrote:
> > One minor nit I've found annoying is that there is no easy way to break out
> > of
> > the loop in vmrun.sh. Breaking into the loader prompt and typing 'reboot'
> > does work, but it requires you to be on the console at the time. What I
> > really want is for 'shutdown -p' or 'poweroff' inside a guest to cleanly
> > shut
> > down and exit the loop in vmrun.sh. To that end, I've implemented support
> > for
> > a few more registers (such of which are non-optional in ACPI) including the
> > Reset Control register (0xcf9), ACPI Power Management 1 Event registers
> > (PM1_EVT) and the ACPI Power Management 1 Control register (PM1_CNT). I
> > added
> > a valid _S5 package and catch writes of the value _S5 specifies to ask bhyve
> > to exit gracefully but with an exit code of 1 (so the loop in vmrun
> > terminates). Most of the PM1 support is very simple (it doesn't support
> > signalling anything for external events as most of them don't make sense).
> > It
> > does perform a reset for writes to the 0xcf9 register however, and also
> > advertises 0xcf9 as the ACPI reset register. (Tested by commenting out the
> > current 0x64 hack.)
> >
> > One thing I had to do was make it possible for an I/O port to request a
> > reset
> > or poweroff, so I added some #define's for additional return codes from
> > in/out handlers. I haven't gone through and changed any existing handlers
> > to
> > use the new constants, but the new handlers make use of INOT_RESET and
> > INOUT_POWEROFF. Note that this also means that the current 0x64 hack could
> > be
> > reimplemented as an in-out handler rather than a special case. I did not
> > explicitly catch VMEXIT_POWEROFF and use a custom exit value in the main
> > loop
> > in bhyverun.c. Instead, I let it fall through to the default and do an
> > exit(1). The patch is all in bhyve itself:
> >
> > --- //depot/vendor/freebsd/src/usr.sbin/bhyve/Makefile
> > +++ //depot/user/jhb/bhyve/usr.sbin/bhyve/Makefile
> > @@ -10,7 +10,7 @@
> > SRCS= acpi.c atpic.c bhyverun.c block_if.c consport.c dbgport.c elcr.c
> > SRCS+= inout.c legacy_irq.c mem.c mevent.c mptbl.c pci_ahci.c
> > SRCS+= pci_emul.c pci_hostbridge.c pci_lpc.c pci_passthru.c
> > pci_virtio_block.c
> > -SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pmtmr.c post.c rtc.c
> > +SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pm.c pmtmr.c post.c rtc.c
> > SRCS+= uart_emul.c virtio.c xmsr.c spinup_ap.c
> >
> > .PATH: ${.CURDIR}/../../sys/amd64/vmm
> > --- //depot/vendor/freebsd/src/usr.sbin/bhyve/acpi.c
> > +++ //depot/user/jhb/bhyve/usr.sbin/bhyve/acpi.c
> > @@ -85,6 +85,8 @@
> > #define BHYVE_ASL_SUFFIX ".aml"
> > #define BHYVE_ASL_COMPILER "/usr/sbin/iasl"
> >
> > +#define BHYVE_PM1A_EVT_ADDR0x400
> > +#define BHYVE_PM1A_CNT_ADDR0x404
> > #define BHYVE_PM_TIMER_ADDR0x408
> >
> > static int basl_keep_temps;
> > @@ -332,9 +344,11 @@
> > EFPRINTF(fp, "[0001]\t\tACPI Disable Value : 00\n");
> > EFPRINTF(fp, "[0001]\t\tS4BIOS Command : 00\n");
> > EFPRINTF(fp, "[0001]\t\tP-State Control : 00\n");
> > - EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : \n");
> > + EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : %08X\n",
> > +BHYVE_PM1A_EVT_ADDR);
> > EFPRINTF(fp, "[0004]\t\tPM1B Event Block Address : \n");
> > - EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : \n");
> > + EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : %08X\n",
> > +BHYVE_PM1A_CNT_ADDR);
> > EFPRINTF(fp, "[0004]\t\tPM1B Control Block Address : \n");
> > EFPRINTF(fp, "[0004]\t\tPM2 Control Block Address : \n");
> > EFPRINTF(fp, "[0004]\t\tPM Timer Block Address : %08X\n",
> > @@ -397,10 +411,10 @@
> > EFPRINTF(fp, "[0001]\t\tBit Width : 08\n");
> > 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 : 0001\n");
> > + EFPRINTF(fp, "[0008]\t\tAddress : 0CF9\n");
> > EFPRINTF(fp, "\n");
> >
> > - EFPRINTF(fp, "[0001]\t\tValue to cause reset : 00\n");
> > + EFPRINTF(fp, "[0001]\t\tValue to cause reset : 06\n");
> > EFPRINTF(fp, "[0003]\t\tRe
Re: [PATCH] Support for S5 (soft power off) in bhyve
Hi John,
This looks good - thanks for adding this support!
I noticed that the RESET_REGISTER is not being advertised in the FACP
flags field. So, perhaps the access to 0xCF9 that you saw during
testing was triggered by cpu_reset_real() as opposed to AcpiReset()?
best
Neel
On Mon, Dec 23, 2013 at 11:43 AM, John Baldwin wrote:
> One minor nit I've found annoying is that there is no easy way to break out of
> the loop in vmrun.sh. Breaking into the loader prompt and typing 'reboot'
> does work, but it requires you to be on the console at the time. What I
> really want is for 'shutdown -p' or 'poweroff' inside a guest to cleanly shut
> down and exit the loop in vmrun.sh. To that end, I've implemented support for
> a few more registers (such of which are non-optional in ACPI) including the
> Reset Control register (0xcf9), ACPI Power Management 1 Event registers
> (PM1_EVT) and the ACPI Power Management 1 Control register (PM1_CNT). I added
> a valid _S5 package and catch writes of the value _S5 specifies to ask bhyve
> to exit gracefully but with an exit code of 1 (so the loop in vmrun
> terminates). Most of the PM1 support is very simple (it doesn't support
> signalling anything for external events as most of them don't make sense). It
> does perform a reset for writes to the 0xcf9 register however, and also
> advertises 0xcf9 as the ACPI reset register. (Tested by commenting out the
> current 0x64 hack.)
>
> One thing I had to do was make it possible for an I/O port to request a reset
> or poweroff, so I added some #define's for additional return codes from
> in/out handlers. I haven't gone through and changed any existing handlers to
> use the new constants, but the new handlers make use of INOT_RESET and
> INOUT_POWEROFF. Note that this also means that the current 0x64 hack could be
> reimplemented as an in-out handler rather than a special case. I did not
> explicitly catch VMEXIT_POWEROFF and use a custom exit value in the main loop
> in bhyverun.c. Instead, I let it fall through to the default and do an
> exit(1). The patch is all in bhyve itself:
>
> --- //depot/vendor/freebsd/src/usr.sbin/bhyve/Makefile
> +++ //depot/user/jhb/bhyve/usr.sbin/bhyve/Makefile
> @@ -10,7 +10,7 @@
> SRCS= acpi.c atpic.c bhyverun.c block_if.c consport.c dbgport.c elcr.c
> SRCS+= inout.c legacy_irq.c mem.c mevent.c mptbl.c pci_ahci.c
> SRCS+= pci_emul.c pci_hostbridge.c pci_lpc.c pci_passthru.c
> pci_virtio_block.c
> -SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pmtmr.c post.c rtc.c
> +SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pm.c pmtmr.c post.c rtc.c
> SRCS+= uart_emul.c virtio.c xmsr.c spinup_ap.c
>
> .PATH: ${.CURDIR}/../../sys/amd64/vmm
> --- //depot/vendor/freebsd/src/usr.sbin/bhyve/acpi.c
> +++ //depot/user/jhb/bhyve/usr.sbin/bhyve/acpi.c
> @@ -85,6 +85,8 @@
> #define BHYVE_ASL_SUFFIX ".aml"
> #define BHYVE_ASL_COMPILER "/usr/sbin/iasl"
>
> +#define BHYVE_PM1A_EVT_ADDR0x400
> +#define BHYVE_PM1A_CNT_ADDR0x404
> #define BHYVE_PM_TIMER_ADDR0x408
>
> static int basl_keep_temps;
> @@ -332,9 +344,11 @@
> EFPRINTF(fp, "[0001]\t\tACPI Disable Value : 00\n");
> EFPRINTF(fp, "[0001]\t\tS4BIOS Command : 00\n");
> EFPRINTF(fp, "[0001]\t\tP-State Control : 00\n");
> - EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : \n");
> + EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : %08X\n",
> +BHYVE_PM1A_EVT_ADDR);
> EFPRINTF(fp, "[0004]\t\tPM1B Event Block Address : \n");
> - EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : \n");
> + EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : %08X\n",
> +BHYVE_PM1A_CNT_ADDR);
> EFPRINTF(fp, "[0004]\t\tPM1B Control Block Address : \n");
> EFPRINTF(fp, "[0004]\t\tPM2 Control Block Address : \n");
> EFPRINTF(fp, "[0004]\t\tPM Timer Block Address : %08X\n",
> @@ -397,10 +411,10 @@
> EFPRINTF(fp, "[0001]\t\tBit Width : 08\n");
> 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 : 0001\n");
> + EFPRINTF(fp, "[0008]\t\tAddress : 0CF9\n");
> EFPRINTF(fp, "\n");
>
> - EFPRINTF(fp, "[0001]\t\tValue to cause reset : 00\n");
> + EFPRINTF(fp, "[0001]\t\tValue to cause reset : 06\n");
> EFPRINTF(fp, "[0003]\t\tReserved : 00\n");
> EFPRINTF(fp, "[0008]\t\tFACS Address : %08X\n",
> basl_acpi_base + FACS_OFFSET);
> @@ -412,7 +426,8 @@
> EFPRINTF(fp, "[0001]\t\tBit Width : 20\n");
> EFPRINTF(fp, "[0001]\t\tBit Offset : 00\n");
> EFPRINTF(fp, "[0001]\t\tEncoded Access Width : 02 [Word
> Access:16]\n");
> - EFPRINTF(fp, "[0008]\t\tAddress : 0001\n");
> + EFPRINTF(fp, "[0008]\t\tAddress : %08X\n",
> + BHYVE_PM1A_EVT_A
[PATCH] Support for S5 (soft power off) in bhyve
One minor nit I've found annoying is that there is no easy way to break out of
the loop in vmrun.sh. Breaking into the loader prompt and typing 'reboot'
does work, but it requires you to be on the console at the time. What I
really want is for 'shutdown -p' or 'poweroff' inside a guest to cleanly shut
down and exit the loop in vmrun.sh. To that end, I've implemented support for
a few more registers (such of which are non-optional in ACPI) including the
Reset Control register (0xcf9), ACPI Power Management 1 Event registers
(PM1_EVT) and the ACPI Power Management 1 Control register (PM1_CNT). I added
a valid _S5 package and catch writes of the value _S5 specifies to ask bhyve
to exit gracefully but with an exit code of 1 (so the loop in vmrun
terminates). Most of the PM1 support is very simple (it doesn't support
signalling anything for external events as most of them don't make sense). It
does perform a reset for writes to the 0xcf9 register however, and also
advertises 0xcf9 as the ACPI reset register. (Tested by commenting out the
current 0x64 hack.)
One thing I had to do was make it possible for an I/O port to request a reset
or poweroff, so I added some #define's for additional return codes from
in/out handlers. I haven't gone through and changed any existing handlers to
use the new constants, but the new handlers make use of INOT_RESET and
INOUT_POWEROFF. Note that this also means that the current 0x64 hack could be
reimplemented as an in-out handler rather than a special case. I did not
explicitly catch VMEXIT_POWEROFF and use a custom exit value in the main loop
in bhyverun.c. Instead, I let it fall through to the default and do an
exit(1). The patch is all in bhyve itself:
--- //depot/vendor/freebsd/src/usr.sbin/bhyve/Makefile
+++ //depot/user/jhb/bhyve/usr.sbin/bhyve/Makefile
@@ -10,7 +10,7 @@
SRCS= acpi.c atpic.c bhyverun.c block_if.c consport.c dbgport.c elcr.c
SRCS+= inout.c legacy_irq.c mem.c mevent.c mptbl.c pci_ahci.c
SRCS+= pci_emul.c pci_hostbridge.c pci_lpc.c pci_passthru.c pci_virtio_block.c
-SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pmtmr.c post.c rtc.c
+SRCS+= pci_virtio_net.c pci_uart.c pit_8254.c pm.c pmtmr.c post.c rtc.c
SRCS+= uart_emul.c virtio.c xmsr.c spinup_ap.c
.PATH: ${.CURDIR}/../../sys/amd64/vmm
--- //depot/vendor/freebsd/src/usr.sbin/bhyve/acpi.c
+++ //depot/user/jhb/bhyve/usr.sbin/bhyve/acpi.c
@@ -85,6 +85,8 @@
#define BHYVE_ASL_SUFFIX ".aml"
#define BHYVE_ASL_COMPILER "/usr/sbin/iasl"
+#define BHYVE_PM1A_EVT_ADDR0x400
+#define BHYVE_PM1A_CNT_ADDR0x404
#define BHYVE_PM_TIMER_ADDR0x408
static int basl_keep_temps;
@@ -332,9 +344,11 @@
EFPRINTF(fp, "[0001]\t\tACPI Disable Value : 00\n");
EFPRINTF(fp, "[0001]\t\tS4BIOS Command : 00\n");
EFPRINTF(fp, "[0001]\t\tP-State Control : 00\n");
- EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : \n");
+ EFPRINTF(fp, "[0004]\t\tPM1A Event Block Address : %08X\n",
+BHYVE_PM1A_EVT_ADDR);
EFPRINTF(fp, "[0004]\t\tPM1B Event Block Address : \n");
- EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : \n");
+ EFPRINTF(fp, "[0004]\t\tPM1A Control Block Address : %08X\n",
+BHYVE_PM1A_CNT_ADDR);
EFPRINTF(fp, "[0004]\t\tPM1B Control Block Address : \n");
EFPRINTF(fp, "[0004]\t\tPM2 Control Block Address : \n");
EFPRINTF(fp, "[0004]\t\tPM Timer Block Address : %08X\n",
@@ -397,10 +411,10 @@
EFPRINTF(fp, "[0001]\t\tBit Width : 08\n");
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 : 0001\n");
+ EFPRINTF(fp, "[0008]\t\tAddress : 0CF9\n");
EFPRINTF(fp, "\n");
- EFPRINTF(fp, "[0001]\t\tValue to cause reset : 00\n");
+ EFPRINTF(fp, "[0001]\t\tValue to cause reset : 06\n");
EFPRINTF(fp, "[0003]\t\tReserved : 00\n");
EFPRINTF(fp, "[0008]\t\tFACS Address : %08X\n",
basl_acpi_base + FACS_OFFSET);
@@ -412,7 +426,8 @@
EFPRINTF(fp, "[0001]\t\tBit Width : 20\n");
EFPRINTF(fp, "[0001]\t\tBit Offset : 00\n");
EFPRINTF(fp, "[0001]\t\tEncoded Access Width : 02 [Word Access:16]\n");
- EFPRINTF(fp, "[0008]\t\tAddress : 0001\n");
+ EFPRINTF(fp, "[0008]\t\tAddress : %08X\n",
+ BHYVE_PM1A_EVT_ADDR);
EFPRINTF(fp, "\n");
EFPRINTF(fp,
@@ -431,7 +446,8 @@
EFPRINTF(fp, "[0001]\t\tBit Width : 10\n");
EFPRINTF(fp, "[0001]\t\tBit Offset : 00\n");
EFPRINTF(fp, "[0001]\t\tEncoded Access Width : 02 [Word Access:16]\n");
- EFPRINTF(fp, "[0008]\t\tAddress : 0001\n");
+ EFPRINTF(fp, "[0008]\t\tAddress : %08X\n",
+ BHYVE_PM1A_CNT_ADDR);
EFPRINTF(fp, "\n");
EFPRINTF(fp,
@@ -603,6 +619,
Re: 11.0-CURRENT panic while running a bhyve instance
Hi Markiyan, Fixed in r259737: http://svnweb.freebsd.org/changeset/base/259737 best Neel On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir wrote: > 2013/12/13 John Baldwin : >> On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: >>> Forgot to fill the Subject: header, re-posting it fixed. >> >> The mailing lists strips attachments, can you post it at a URL? >> > > Shared here: > > https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing > > -- > Markiyan. > >>> -- >>> Markiyan >>> >>> >>> -- Forwarded message -- >>> From: Markiyan Kushnir >>> Date: 2013/12/13 >>> Subject: >>> To: freebsd-curr...@freebsd.org, freebsd-virtualization@freebsd.org >>> >>> >>> I started some ports to compile inside a bhyve instance: >>> >>> root@vm:~ # uname -a >>> FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 >>> r259250: Thu Dec 12 14:17:32 EET 2013 >>> r...@vm.mkushnir.zapto.org:/ >>> usr/obj/usr/src.svnup/sys/MAREK amd64 >>> >>> and left it running unattended. Approx. 2 hours later the host went to >>> panic. The bhyve instance survived after the panic and I could be able >>> to complete my ports compilation. >>> >>> core.txt attached (gzipped) >>> ___ >>> freebsd-curr...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >>> >> >> -- >> John Baldwin > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Panic starting a bhyve guest after resume
Hi John, On Fri, Dec 20, 2013 at 2:23 PM, John Baldwin wrote: > On Friday, December 13, 2013 9:28:29 pm Neel Natu wrote: >> Hi John, >> >> On Fri, Dec 13, 2013 at 2:09 PM, John Baldwin wrote: >> > On Thursday, December 12, 2013 4:00:08 pm Neel Natu wrote: >> >> Hi John, >> >> >> >> On Thu, Dec 12, 2013 at 12:11 PM, John Baldwin wrote: >> >> > If I suspend and resume my laptop and then try to start a guest after >> >> > the >> >> > resume, I get an odd panic. It generates a privileged instruction >> >> > fault (in >> >> > kernel mode) for 'vmclear'. I've checked CR4 and it claims that VMXE >> >> > is set. >> >> > I dont have any other ideas off the top of my head on what I should be >> >> > poking >> >> > at? It looks like we read a bunch of MSRs in vmx_init(), but we don't >> >> > write >> >> > to them, and all vmx_enable() does on each CPU is set VMXE in CR4 from >> >> > what I >> >> > can tell. >> >> > >> >> >> >> It also does a "vmxon" on each logical cpu which may also need to be >> >> done after a resume. >> > >> > Ah, yes it does. That was sufficient both for starting a new guest after >> > resume and even doing a suspend/resume while a guest was active (and the >> > guest continued to run fine). I have a hacky patch for this. One, it >> > includes both a suspend and resume hook for VMM, though for my testing I >> > only >> > needed a resume hook to invoke vmxon. Second, the name of vmx_resume2() >> > is a total hack (because vmx_resume() was already taken. I think for now >> > if I were to commit this, I'd just add the resme hook and maybe call the >> > Intel method vmx_reset() or vmx_restore()? >> > >> > http://people.freebsd.org/~jhb/patches/bhyve_resume.patch >> > >> >> There seems to be a race after the APs are restarted and before >> 'vmm_resume_p()' where it would be problematic to execute a VMX >> instruction. >> >> Perhaps we should enable VMX on each cpu before they return to the >> interrupted code? > > I've updated the patch at the URL above to do just that. This also works > in my testing. > Looks great! best Neel > -- > John Baldwin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Panic starting a bhyve guest after resume
On Friday, December 13, 2013 9:28:29 pm Neel Natu wrote: > Hi John, > > On Fri, Dec 13, 2013 at 2:09 PM, John Baldwin wrote: > > On Thursday, December 12, 2013 4:00:08 pm Neel Natu wrote: > >> Hi John, > >> > >> On Thu, Dec 12, 2013 at 12:11 PM, John Baldwin wrote: > >> > If I suspend and resume my laptop and then try to start a guest after the > >> > resume, I get an odd panic. It generates a privileged instruction fault > >> > (in > >> > kernel mode) for 'vmclear'. I've checked CR4 and it claims that VMXE is > >> > set. > >> > I dont have any other ideas off the top of my head on what I should be > >> > poking > >> > at? It looks like we read a bunch of MSRs in vmx_init(), but we don't > >> > write > >> > to them, and all vmx_enable() does on each CPU is set VMXE in CR4 from > >> > what I > >> > can tell. > >> > > >> > >> It also does a "vmxon" on each logical cpu which may also need to be > >> done after a resume. > > > > Ah, yes it does. That was sufficient both for starting a new guest after > > resume and even doing a suspend/resume while a guest was active (and the > > guest continued to run fine). I have a hacky patch for this. One, it > > includes both a suspend and resume hook for VMM, though for my testing I > > only > > needed a resume hook to invoke vmxon. Second, the name of vmx_resume2() > > is a total hack (because vmx_resume() was already taken. I think for now > > if I were to commit this, I'd just add the resme hook and maybe call the > > Intel method vmx_reset() or vmx_restore()? > > > > http://people.freebsd.org/~jhb/patches/bhyve_resume.patch > > > > There seems to be a race after the APs are restarted and before > 'vmm_resume_p()' where it would be problematic to execute a VMX > instruction. > > Perhaps we should enable VMX on each cpu before they return to the > interrupted code? I've updated the patch at the URL above to do just that. This also works in my testing. -- John Baldwin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-virtualization@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE o kern/148155 virtualization[vimage] [pf] Kernel panic with PF + VIMAGE kernel opt a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail 7 problems total. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
