Re: bhyve passthru problem
Oleksandr,I would like to try an experiment to try to fix your problem. If you agree,I could send you my bhyve and vmm.ko files,if you want. I suspect that they may fix your problem. Let me know if you want to try. On Fri, Jun 14, 2024 at 8:35 AM Corvin Köhne wrote: > On Thu, 2024-06-13 at 10:53 +0300, Oleksandr Kryvulia wrote: > > I'm trying to passthru a wwan-adapter to linux guest using > > sysutils/vm-bhyve-devel. > > > > ppt0@pci0:8:0:0:class=0x0d4000 rev=0x01 hdr=0x00 > > vendor=0x8086 device=0x7560 subvendor=0x1cf8 subdevice=0x8654 > > vendor = 'Intel Corporation' > > device = 'XMM7560 LTE Advanced Pro Modem' > > class = wireless controller > > subclass = cellular controller/modem > > > > The guest does not start with an error: > > > > bhyve: passthru device 8/0/0 BAR 2: base 0xbc201000 or size 0x100 > > not page aligned > > bhyve: failed to initialize BARs for PCI 8/0/0 > > Device emulation initialization error: No such file or directory > > > > What I am doing wrong? > > > > The BAR size of your device is smaller than a page. Unfortunately, you > can't change it, so there's nothing you can do right now. > > I don't know why bhyve validates the BAR size. The commit adding this > check is old [1] and doesn't explain it. What bhyve could do is > rounding up the BAR size to a full page size when allocating memory for > the BAR. > > [1] https://github.com/freebsd/freebsd- > src/commit/7a902ec0eccc752c9c38533ed123121eaaea1225 > > > -- > Kind regards, > Corvin > -- Mario.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #11 from mario felicioni --- I have compiled the source code of Mark Peek with the patch and it worked. So now Rufus can detect the USB disks inside a Windows vm. Very thanks. -- You are receiving this mail because: You are the assignee for the bug.
Re: bhyve passthru problem
I don't know why bhyve validates the BAR size. The commit adding this check is old [1] and doesn't explain it. What bhyve could do is rounding up the BAR size to a full page size when allocating memory for the BAR. [1] https://github.com/freebsd/freebsd- src/commit/7a902ec0eccc752c9c38533ed123121eaaea1225 At the time, BIOSs would often place device BARs of less than a page size in the same physical page. Since EPT only gives page granularity, this would result in all those devices being available to the guest even if they hadn't been passed through. later, Peter.
[Bug 279729] virtualization/bhyve: we are forced to passthru the whole IOMMU group of a GPU and not the single slots.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279729 Mark Linimon changed: What|Removed |Added Component|Individual Port(s) |bhyve Version|Latest |15.0-CURRENT Assignee|ports-b...@freebsd.org |virtualization@FreeBSD.org Product|Ports & Packages|Base System -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279729] virtualization/bhyve: we are forced to passthru the whole IOMMU group of a GPU and not the single slots.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279729 mario felicioni changed: What|Removed |Added Version|15.0-CURRENT|14.0-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279732] AWS/EC2 /dev/aws/disk/ebs/ devices not created after 14.1-STABLE stable/14-n267826-1e3dfe0c343c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279732 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|virtualization@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279732] AWS/EC2 /dev/aws/disk/ebs/ devices not created after 14.1-STABLE stable/14-n267826-1e3dfe0c343c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279732 Mark Linimon changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #3 from Mark Linimon --- ^Triage: Cc: committer of D45347 even though this does not seem cause-and-effect to me. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 Mark Peek changed: What|Removed |Added Status|New |Closed Resolution|--- |Not A Bug --- Comment #12 from Mark Peek --- I'm closing this as "not a bug" for FreeBSD since the needed change/workaround was PR'd back into the rufus repo. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279738] Hyper-V: Kernel panic: acquiring blockable sleep lock with spinlock or critical section held
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279738 Mark Linimon changed: What|Removed |Added Keywords||crash Assignee|b...@freebsd.org|virtualization@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279738] Hyper-V: Kernel panic: acquiring blockable sleep lock with spinlock or critical section held
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279738 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #3 from Konstantin Belousov --- No, they call contigmalloc() from smp_rendezvous() action. This was discussed in private with wen@. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279738] Hyper-V: Kernel panic: acquiring blockable sleep lock with spinlock or critical section held
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279738 --- Comment #4 from Gordon Bergling --- (In reply to Mark Johnston from comment #1) Hi Mark, I applied D45596 on a fresh build, but the crash is still the same. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279738] Hyper-V: Kernel panic: acquiring blockable sleep lock with spinlock or critical section held
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279738 --- Comment #5 from Wei Hu --- This is due to calling contigmalloc() from smp_rendezvous(). Even passing the M_NOWAIT flag, on smaller memory sized VM it still reach vmem_xalloc in the path and tries to grab sleep lock by calling VMEM_LOCK(vm). I will try to move the contigmalloc call out of smp_rendezvous. -- You are receiving this mail because: You are the assignee for the bug.
