The patch that has been mentioned in the last comment has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=31e6a7b17b35711eb44f0e
... and has been released with QEMU v2.8 already, so marking this as "fix
released" now.
** Changed in: qemu
Status: New => Fix Released
--
Hi *,
it seems we could finally fix this bug:
https://bugs.launchpad.net/qemu/+bug/1384892
with the following patches:
https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07260.html
Regards,
Thorsten
Am 22.06.2016 um 13:10 schrieb T. Huth:
> Alex' patch has been included here:
>
Current QEMU code is quite different now.
When I tested last (with QEMU 2.4) the problem still existed.
I had quite a discussion with Alex up to and around end of 2015,
but unfortunately since then I just did not have any spare time to
convince Alex to accept what I call 'the real fix', a series
Alex' patch has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=69970fcef937bddd7f745
... so I assume this ticket could be closed now?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I made some time for limited testing.
The released V2.1 puts the vfio-ed RTL8168 into a zombie state when running an
IPFire VM, which requires a subsequent POWER cycle in order to let mii-tools
show anything else than 'no link' (i.e. to get the LED back on). Pushing the
reset button on the x64
I just tried an ipfire 2.17 core 92 VM with assigned rtl8168 using the
patches I posted last night:
http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg03528.html
The rtl NIC works fine in the guest and tracing shows that the guest
never accesses the MSI-X table backdoor (nor should it
Yes, thank you, that adapted patch looks good to me.
It seems V2.4 based though, so it would need to be backported down to 2.3
through 2.1.
Is there an established process for that kind of backporting need ?
Do you confirm my 'not reached' hypothesis (which would explain why your
patch #4 did
Thorsten, is this the patch you're suggesting then?
http://fpaste.org/244037/43684040/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1384892
Title:
RTL8168 NIC VFIO not working anymore since QEMU
After investigating a little more I have the impression, that
a) Alex's patch #4 is required
and
b) 'val' does not need to be initialised
Thus remains replacing each of the two instances of 0x1000U with
0x8000U,
where it remains open whether the 'xor' operation (now on bit 31 rather than
Alex, are you sure about the constant 0x1000U (bit 27) being used in the
code below ?
Shouldn't it rather be a 0x8000U (bit 31 which you commented about) ?
I added a /* NOT REACHED ? */ below, as I feel that might be the problem.
Florian,
are you willing to test the so modified source
I had too many problems with the Chipset so I decided to sell the System.
As a result I cannot test for this bug anymore, sorry.
Thanks anyway for your effort on this problem!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
launchpad mangled that pretty good, maybe this is better -
http://fpaste.org/148539/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1384892
Title:
RTL8168 NIC VFIO not working anymore since QEMU
Does this improve anything? Reviewing the quirk seems to show there's a
bug in how we're writing to the MSI-X table. Not sure how it worked
before. Tested this with a Win8.1 VM and assigned RTL8111/8168/8411.
Thanks.
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -1834,8 +1834,8 @@ static void
I disabled vfio_probe_rtl8168_bar2_window_quirk() as you suggested and indeed,
the problem is gone now using QEMU 2.1.2.
RTL really isn't the best choice, I guess.
Thanks for your quick reply!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
In general, rtl is a terrible choice for a device assignment NIC in my
experience. Intel NICs are much better and worth the extra cost.
However, QEMU2.1 did attempt to add a quirk for RTL8168 that allows the
Windows driver to work correctly in a guest. In my testing, the Linux
driver never made
15 matches
Mail list logo
