Hi,
I would like to invoke QEMU and KVM so that the guest sees a virtio
NIC, and that NIC goes through a SR-IOV VF of a host NIC as directly
and efficiently as possible. But I don't actually want to pass the VF
through to the guest. I've found a bunch of discussion and confusing
examples on the
Hi everyone,
I'm updating my dev environment to use the shiny new vfio
infrastructure for PCI assignment to kvm guests, and I'm not able to
do what I used to do with the old-school KVM passthrough. In
particular, I have, say, a two-port QLogic adapter that looks like:
82:00.0 0200: 1077:8030
On Tue, Mar 27, 2012 at 3:24 PM, Roland Dreier wrote:
> Just to follow up on this, it turns out this is a bug in how the
> Mellanox firmware deals with FLR (function level reset). The
> FW will be fixed in a future release, but in the meantime I've
> been able to work aro
On Sun, Jan 29, 2012 at 6:29 PM, Roland Dreier wrote:
> I'm having a strange problem passing an mlx4 device into a kvm guest.
> The device in question is:
>
> 05:00.0 InfiniBand [0c06]: Mellanox Technologies MT26428 [ConnectX
> VPI PCIe 2.0 5GT/s - IB QDR / 10GigE]
Hi everyone,
I'm having a strange problem passing an mlx4 device into a kvm guest.
The device in question is:
05:00.0 InfiniBand [0c06]: Mellanox Technologies MT26428 [ConnectX
VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] [15b3:673c] (rev b0)
running the latest (I believe) FW version 2.9.1000. The
> > This is Linux virtualization, where _both_ the host and the guest source
> > code
> > is fully known, and bugs (if any) can be found with a high degree of
> It may sound strange but Windows is very popular guest and last I
> checked my HW there was no Windows sources there, but the an
> > I have a (32-bit) Windows XP guest installed, and if I start kvm-82
> > (from the Debian packages) on a 2.6.29-rc1 kernel (running 64-bit on an
> > AMD host), the guest boots but soon dies with messages along the lines
> > of:
> >
> > lsi_scsi: error: Unimplemented message 0x0c
> >
I have a (32-bit) Windows XP guest installed, and if I start kvm-82
(from the Debian packages) on a 2.6.29-rc1 kernel (running 64-bit on an
AMD host), the guest boots but soon dies with messages along the lines
of:
lsi_scsi: error: Unimplemented message 0x0c
lsi_scsi: error: Reselect with
> I suspect it's a case of off-by-one... ALIGN() might round down, and
> the "+ (PAGE_SIZE-1)" was there to make it round up.
> Except for that missing -1 ...
ALIGN() has always rounded up, at least back to 2.4.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a
> I'm guessing that the missing comment explains that this is
> intentional, to trap buffer overflows?
Actually, speaking of comments, it's interesting that
__get_vm_area_node() -- which is called from vmalloc() -- does:
/*
* We always allocate a guard page.
*/
> + ctrl = pci_ari_enabled(dev) ? PCI_IOV_CTRL_ARI : 0;
> + pci_write_config_word(dev, pos + PCI_IOV_CTRL, ctrl);
> + ssleep(1);
You seem to sleep for 1 second wherever you write the IOV_CTRL
register. Why is this? Is this specified by PCI, or is it coming from
somewhere els
> ARI is an independent PCI Express extended capability. Multi-function
> devices supporting this capability may use it to track dependency
> between different functions and assign function group numbers to
> these functions.
> Another reason to keep this separated with SR-IOV is that after A
> > +config PCI_ARI
> > + bool "PCI ARI support"
> > + depends on PCI
> > + default n
> > + help
> > +This enables PCI Alternative Routing-ID Interpretation.
>
> This Kconfig help text is a little weak. Why not include the text
> you've already written here:
>
> Support Al
> Hm, your comment later on makes me think you tried this on AMD. If so, I
> have
> also run into a similar problem with Windows guests under AMD. After
> installing
> WinDbg, it told me that it was a "Paging Request in Non-Paged memory"
> related to
> the Video memory area. Does yours
> Known problem:
> http://www.nabble.com/LSI:-avoid-infinite-loops-p17116605.html
I tried this hack (and actually made the magic insns number 500), and
doing an XP install I got
lsi_scsi: error: Reselect with pending DMA
do you have any feeling if this is because the script execution got
s
> > BTW I tried using if=ide to install Windows XP and got a blue screen
. > during the installer. What are people doing to run XP in a kvm guest?
Funnily enough installing XP SP2 with if=ide worked fine on an Intel
host. I notice that I left off -std-vga on the working install too (I
used it
> > BTW I tried using if=ide to install Windows XP and got a blue screen
> > during the installer. What are people doing to run XP in a kvm guest?
> Are you using a recent version of kvm-userspace/kernel modules? Please
> save the blue screen and mail it to the list or fill a bug.
Pretty rec
> Known problem:
> http://www.nabble.com/LSI:-avoid-infinite-loops-p17116605.html
> Windows driver has scripts code which busy loops on main memory. Since
> that executes in vcpu context, the cpu won't ever get a chance to change
> the variable which the SCSI emulation is looping at.
Thanks
I built with debugging symbols, and this seems to be an issue with SCSI
disk emulation. The traceback is:
#0 0x7fc086d7dd10 in memcpy () from /lib/libc.so.6
#1 0x004a319b in cpu_physical_memory_rw (addr=108661608,
buf=0x7fff904ca190 "\224['\206\210\030z\006I�A", len=4, is_write=
> I experienced random hangs during the install (stracing kvm shows no
> system calls, and it appears to be spinning at 100% CPU), but eventually
> I got an install that ran all the way to completion. However, that
> image seems to hang every time shortly after boot starts. I see the
> Windo
> > > + kmalloc(GFP_KERNEL, sizeof(struct
> > kvm_pv_mmu_op_buffer));
> > Surely this produces a warning? kmalloc takes (size, flags) -- you have
> > them reversed here.
> Heh. It actually doesn't.
Yeah, I guess you need sparse to catch the gfp_t mismatch.
> > kfree(NU
> +struct kvm_pv_mmu_op_buffer *buffer =
> +kmalloc(GFP_KERNEL, sizeof(struct kvm_pv_mmu_op_buffer));
Surely this produces a warning? kmalloc takes (size, flags) -- you have
them reversed here.
> +lapic = kzalloc(GFP_KERNEL, sizeof(*lapic));
> +lapic =
> Yes, things like kvm_lapic_state are way too big to be on the stack.
I had a quick look at the code, and my worry about dynamic allocation
would be that handling allocation failure seems like it might get
tricky. Eg for handling struct kvm_pv_mmu_op_buffer (which is 528 bytes
on the stack in k
23 matches
Mail list logo
