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:
> http:/
I tested these
https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg05900.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg05901.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg05902.html
together with [Qemu-devel] [PULL 18/19] vfio/pci: Fix
vfio_rtl8168_q
Am 22.10.2016 um 17:09 schrieb Alex Williamson:
On Sat, 22 Oct 2016 11:10:59 +0200
Thorsten Kohfeldt wrote:
Hi *,
this came to my mind when browsing the sources in the patch's vicinity.
It is just a collection of thoughts, so please don't feel offended
about how I phras
on't particularly like qword accesses
(Realtek NICs are such a device). This actually also fixes memory
inspection via the xp command in the QEMU monitor as well.
Please comment. Is this the best way to solve this problem? Thanks
Reported-by: Thorsten Kohfeldt
Signed-off-by: Alex Williams
Am 10.10.2016 um 17:18 schrieb Alex Williamson:
On Sun, 9 Oct 2016 19:56:03 +0200
Thorsten Kohfeldt wrote:
From: Thorsten Kohfeldt
Date: Sat, 24 Sep 2016 20:43:20 +0200
Subject: [PATCH] vfio: Fix vfio_rtl8168_quirk_data_read address offset
Introductory comment for rtl8168 VFIO MSI-X quirk
From: Thorsten Kohfeldt
Date: Sat, 24 Sep 2016 20:43:20 +0200
Subject: [PATCH] vfio: Fix vfio_rtl8168_quirk_data_read address offset
Introductory comment for rtl8168 VFIO MSI-X quirk states:
At BAR2 offset 0x70 there is a dword data register,
offset 0x74 is a dword address register
(Re-post, as my mail client somehow made my previous post attach to the wrong
thread.
I do not mean to spam y'all, but maybe my previous mail got lost in your
filters ...
... as I have not yet seen any answer to my questions/remarks.
)
> On 2016/9/14 6:55, Alex Williamson wrote:
>
> [cc +Paolo
> On 2016/9/14 6:55, Alex Williamson wrote:
>
> [cc +Paolo]
>
>> On Thu, 11 Aug 2016 19:05:57 +0800
>> Yongji Xie wrote:
>>
>> Now the kernel commit 05f0c03fbac1 ("vfio-pci: Allow to mmap
>> sub-page MMIO BARs if the mmio page is exclusive") allows VFIO
>> to mmap sub-page BARs. This is the corr
Am 20.09.2016 um 20:46 schrieb Laszlo Ersek:
On 09/20/16 20:23, Thorsten Kohfeldt wrote:
Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:
I think it would make sense to work from the pre-rendered FlatView,
if the information you can get out of it covers your needs.
I assume you know by now
Am 20.09.2016 um 09:56 schrieb Paolo Bonzini:
... dumping the flat-view would give you something much simpler:
-0009 (RW): pc.ram
000a-000b (RW): vga-lowmem
000c-000f (R-): pc.ram @ 000c
0010-00
Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:
On 09/20/16 02:16, Thorsten Kohfeldt wrote:
Am 15.09.2016 um 11:52 schrieb Paolo Bonzini:
On 07/09/2016 02:48, Thorsten Kohfeldt wrote:
From: Thorsten Kohfeldt
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info
Am 15.09.2016 um 11:52 schrieb Paolo Bonzini:
On 07/09/2016 02:48, Thorsten Kohfeldt wrote:
From: Thorsten Kohfeldt
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo
Motivation
When 'tuning' 'quirks'
From: Thorsten Kohfeldt
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo
Motivation
When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
directly grasp the implications of the priorisati
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 of
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 m
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 not
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 wit
18 matches
Mail list logo
