Re: Booting 9front on bhyve

[Tycho Nightingale via freebsd-virtualization]

Hi,

On Dec 14, 2016, at 5:44 PM, Piotr Kubaj via freebsd-virtualization 
 wrote:

> Is it possible to use other mouse drivers, ps2intellimouse etc.?

Not at this point as the emulation doesn’t currently support the ps2 
intellimouse.

Tycho
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: bhyve: disable msi and msix on virtio reset?

[Tycho Nightingale via freebsd-virtualization]

Hi,

On Jul 12, 2016, at 7:38 PM, Peter Grehan  wrote:

>> Yes, writing 0 to the status resister should reset the device
>> including all PCIE state.  This implies that vi_reset_dev() needs to
>> take the proper actions to bring the associated pci_devinst (which
>> from the guest’s perspective isn’t a discrete element) back to it’s
>> reset state too.
> 
> I'm not sure if the reset also hits PCIe state, if you're counting config 
> space as part of that (e.g. BAR contents). As an example, the FreeBSD guest 
> virtio code doesn't do any config space saves/restores around a reset.

This is one of those ambiguities in the virtio spec wherein the canonical 
implementation (qemu) becomes the de facto standard.  I see in illumos driver 
that only a virtio-reset is performed in the quiesce entry point.  On qemu Is 
this sufficient on qemu to support warm rest?  If so then perhaps we should 
only clear the capabilities (MSIX) and not the BARs.

Tycho
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: bhyve: disable msi and msix on virtio reset?

[Tycho Nightingale via freebsd-virtualization]

Hi,

Yes, writing 0 to the status resister should reset the device including all 
PCIE state.  This implies that vi_reset_dev() needs to take the proper actions 
to bring the associated pci_devinst (which from the guest’s perspective isn’t a 
discrete element) back to it’s reset state too.

Tycho

On Jul 12, 2016, at 8:27 AM, Andriy Gapon  wrote:

> 
> A write of a zero to VTCFG_R_STATUS initiates a virtio device reset via
> vc_reset.  Typically this means a call to vi_reset_dev() which resets a
> bunch of fields in virtio_softc, but does not touch a corresponding
> pci_devinst (hanging off vs_pi) at all.  Among other things this means
> that PCI MSI and MSI-X states remain unchanged.  One of the consequences
> is that we keep using virtio_config_size of 24 if MSI-X is enabled.
> 
> Should the virtio status reset also reset the PCI state?
> 
> One practical problem that I see is with illumos fast reboot where the
> illumos virtio driver assumes that the status reset is sufficient to
> return a device to a state like after a clean (full) reboot.
> 
> Thank you.
> -- 
> Andriy Gapon
> ___
> freebsd-virtualization@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscr...@freebsd.org"

___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: bhyve / libvmmapi usage

[Tycho Nightingale via freebsd-virtualization]

Hi,

libvmmapi exists to support bhyveload and bhyve.  It's as you say an internal 
library.  While there is obviously nothing to preclude it’s use by others, I 
wouldn’t consider it’s interfaces “public” nor “stable”.  Furthermore, though 
there has been some consideration taken not to recycle the kernel interface 
ioctls, I’d also classify those interfaces as “private” and “unstable”.

Tycho

On Jun 24, 2016, at 9:09 AM, Roman Bogorodskiy  wrote:

> Hi,
> 
> A couple of questions on the libvmmapi lib:
> 
> - Is that a "public" library intended for a wide audience or sort of an
>  internal lib to be used by bhyve(8) and friends? 
> - Somewhat continuation of the first question: any expectations on
>  libvmmapi API/ABI stability?
> 
> Thanks,
> 
> Roman Bogorodskiy

___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: Illumos boot

[Tycho Nightingale via freebsd-virtualization]

Hi,

Please see inline.

On Oct 13, 2015, at 7:17 AM, Matt Churchyard via freebsd-virtualization 
 wrote:

> In my quest to continue expanding guest support in my vm-bhyve utility (See 
> https://github.com/churchers/vm-bhyve :) ), I've found the Windows support 
> pretty solid once I got clear on the slot requirements. I'm now trying an OS 
> that requires CSM (Illumos) but unfortunately I'm currently struggling to get 
> it to boot up correctly.
> 
> Here's an example of the command I'm generating at the moment (This is 
> running on an Intel Core-i3):
> 
> bhyve -c 2 -m 2G -s 0,hostbridge -s 31,lpc \
>  -s 3,ahci-cd,/data/vm/.iso/smartos-latest.iso \
>  -s 4:0,ahci-hd,/data/vm/smartos/disk0.img \
>  -s 5:0,virtio-net,tap0 \
>  -l com1,stdio -l com2,/dev/nmdm2A \
>  -H -l bootrom,/data/vm/.config/BHYVE_UEFI_CSM.fd \
>  smartos
> 
> I have com1 set to stdio so I can easily watch the output as it runs.
> It tends to get as far as "Legacy INT19 Boot...", then fall over.
> Depending on whether I put the network interface directly in the slot after 
> the HDD, I seem to get different errors -
> 
> slot 3 - cd
> slot 4 - hdd
> slot 5 - virtio-net
> 
> panic[cpu0]/thread=ff01457cdb40: BAD TRAP: type=e (#pf Page fault) 
> rp=ff0004a69a60 addr=40 occurred in module "genunix" due to a NULL 
> pointer dereference
> 
> slot 3 - cd
> slot 4 - hdd
> slot 7 - virtio-net
> 
> panic[cpu1]/thread=ff0004002c40: BAD TRAP: type=d (#gp General 
> protection) rp=ff0004002740 addr=0
> 
> On com2 I see the boot menu, then one and a half lines of dots. The second 
> line of dots stops about 2/3 of the way across.

Have you tried booting illumos in verbose mode — edit the grub command line and 
provide ‘-v’.  That may give you a better backtrace than a program counter.

> Interestingly, my code normally puts the CD after the HDD, which Windows 
> seems happy with as long as the slots are consecutive.
> In SmartOS this gives me a different error:
> 
> slot 3 - hdd
> slot 4 - cd
> slot 5 - virtio-net
> 
> PlatformBdsBootFail
> Boot Failed. Harddisk 1
>  Find PE image 
> /home/grehan/proj/stock_edk2/Build/BhyveX64/DEBUG_GCC48/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll
>  (ImageBase=7F8DC000, EntryPoint=7F8DC2AF) 

This error is from the UEFI code.  It implies that the CSM boot failed or was 
never invoked.  If the HDD isn’t bootable, yet the CD is, that is the most 
likely source as the CSM assumes the first block device it encounters is the 
desired boot source.

Tycho
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"