address_space_rw() access size must be multiplied by width.
dp8393x_receive() must return the number of bytes read, not the length
of the last memory access.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/net/dp83
From: Laurent Vivier
Signed-off-by: Laurent Vivier
---
hw/mips/mips_jazz.c | 2 +-
hw/scsi/esp.c | 330 +-
include/hw/scsi/esp.h | 15 ++-
3 files changed, 313 insertions(+), 34 deletions(-)
diff --git a/hw/mips/mips_jazz.c b/hw/mips
Signed-off-by: Laurent Vivier
---
hw/input/adb-kbd.c | 4
hw/input/adb-mouse.c | 4
hw/input/adb.c | 33 +
hw/misc/mac_via.c | 27 ++-
include/hw/input/adb.h | 1 +
5 files changed, 60 insertions(+), 9 deletio
From: Laurent Vivier
This is broken as the linux driver seems broken too...
Signed-off-by: Laurent Vivier
---
hw/audio/Makefile.objs | 1 +
hw/audio/asc.c | 492 +
include/hw/audio/asc.h | 21 +++
3 files changed, 514 insertions(+)
cr
The card is not able to exit from exhaustion state, because
while the drive consumes the buffers, the RRP is incremented
(when the driver clears the ISR RBE bit), so it stays equal
to RWP, and while RRP == RWP, the card thinks it is always
in exhaustion state. So the driver consumes all the buffers
Signed-off-by: Laurent Vivier
---
hw/block/Makefile.objs | 1 +
hw/block/swim.c| 325 +
2 files changed, 326 insertions(+)
create mode 100644 hw/block/swim.c
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index 53ce5751ae..
From: Laurent Vivier
Signed-off-by: Laurent Vivier
---
default-configs/m68k-softmmu.mak | 12 ++
hw/display/macfb.c | 31 ++--
hw/m68k/Makefile.objs| 6 +-
hw/m68k/bootinfo.h | 99 ++
hw/m68k/mac.c| 384 +++
It's only 32 bytes, and this simplifies the dp8393x_get()/
dp8393x_put() interface.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 107 ++-
1 file changed, 51 insertions(+), 56 deletions(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.
Signed-off-by: Laurent Vivier
---
hw/Makefile.objs | 1 +
hw/display/macfb.c | 67 +++-
hw/nubus/Makefile.objs | 4 +
hw/nubus/mac.c | 112 +++
hw/nubus/nubus-bridge.c | 34 ++
hw/nubus/nubus-bus.c | 60 +++
hw/nubus/nubus-
From: Laurent Vivier
Signed-off-by: Laurent Vivier
---
arch_init.c | 4 +
hw/display/Makefile.objs| 1 +
hw/display/macfb-template.h | 158 +
hw/display/macfb.c | 283
qemu-options.hx
On 08.06.2018 17:58, Patryk Olszewski wrote:
> W dniu 08.06.2018 o 17:25, Peter Maydell pisze:
>> On 8 June 2018 at 06:47, Thomas Huth wrote:
>>> On 07.06.2018 23:08, Philippe Mathieu-Daudé wrote:
Remove the 'stair-step output' on stdio.
This partially reverts commit 12fb0ac05, whic
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the gue
Signed-off-by: Laurent Vivier
---
hw/input/adb.c| 99 -
hw/misc/Makefile.objs | 1 +
hw/misc/mac_via.c | 940 ++
include/hw/input/adb.h| 8 +
include/hw/misc/mac_via.h | 45 +++
5 files changed, 1092 insertions(+),
The previous commit added Block Limits emulation for scsi-block devices
if the underlying hardware does not implement it. But this is not
enough to fix the issue of max_io_sectors mismatch between the
guest and the host - the guest is not aware of the Block
Limits support we're now providing.
This
This is needed by Quadra 800, this card can run on little-endian
or big-endian bus.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 101 ++-
1 file changed, 70 insertions(+), 31 deletions(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.
The previous patches implemented a way to deliver an emulated
Block Limits (BL) response for the guest in case the underlying
hardware does not support this page.
However, the approach used is crude. We're executing the logic for
all SCSI devices, regardless of whether they need it or not. There's
When using SCSI passthrough and running in Linux, QEMU edits the
reply of the SCSI Inquiry VPD Block Limits message with the value
of the /sys/bus//queue/max_sectors_kb parameter the device
has in the host. Doing so allows the Linux guest to proper setup
the device.
But the Block Limits message is
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180608152353.98712-1-vsement...@virtuozzo.com
Subject: [Qemu-devel] [PATCH v4 0/6] NBD e
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180608200558.386-1-laur...@vivier.eu
Subject: [Qemu-devel] [RFC 00/13] hw/m68k: add Apple Machintosh Quadra 800
machine
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=
On 06/07/2018 06:34 PM, Cornelia Huck wrote:
On Thu, 7 Jun 2018 18:17:57 +0200
Halil Pasic wrote:
On 06/07/2018 11:54 AM, Cornelia Huck wrote:
Hm, I think we need to be more precise as to what scsw we're talking
about. Bad ascii art time:
--
| scsw(g) | ssch
--
On 06/08/2018 12:44 AM, Philippe Mathieu-Daudé wrote:
> On 01/09/2018 11:01 AM, Peter Maydell wrote:
>> Since omap_mmc is still using the legacy SD card API, the SD
>> card created by sd_init() is not plugged into any bus. This
>> means that the controller has to reset it manually.
>>
>> Failing to
When guest CPU PM is enabled, and with -cpu host, expose the host CPU
MWAIT leaf to guest so guest can make good PM decisions.
Signed-off-by: Michael S. Tsirkin
---
This builds but is untested. Is this a reasonable way to go about it?
target/i386/cpu.h | 9 +
target/i386/cpu.c | 18 ++
On 06/08/2018 04:45 PM, Cornelia Huck wrote:
On Fri, 8 Jun 2018 15:13:28 +0200
Halil Pasic wrote:
On 06/08/2018 02:20 PM, Cornelia Huck wrote:
My proposal is to do the same
copying to scsw(r) again, which would mean we get a request with both
the halt and the start bit set. The vfio code n
On 6/6/2018 9:20 AM, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 08:31:41AM -0500, Tom Lendacky wrote:
>> On 6/4/2018 3:07 PM, Eduardo Habkost wrote:
>>> On Fri, Jun 01, 2018 at 11:38:08AM -0400, Konrad Rzeszutek Wilk wrote:
AMD future CPUs expose _two_ ways to utilize the Intel equiva
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180608205830.308627-1-...@redhat.com
Subject: [Qemu-devel] [RFC untested PATCH] i386/cpu
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180608123307.24773-1-alex.ben...@linaro.org
Subject: [Qemu-devel] [PATCH v6 00/49] fix building of tests/tcg
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(gi
Introduce the auto_topoext bit to to control topoext feature.
Also add new field auto_topoext(in X86CPUDefinition). This will
be used to enable topoext on newer CPU models where topoext can
be supported.
Signed-off-by: Babu Moger
---
include/hw/i386/pc.h | 4
target/i386/cpu.c| 12 +++
This series enables the TOPOEXT feature for AMD CPUs. This is required to
support hyperthreading on kvm guests.
This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506
v13:
Patches are based off of Eduard
Enable TOPOEXT feature on EPYC CPU. This is required to support
hyperthreading on VM guests. Also extend xlevel to 0x801E.
TOPOEXT feature is disabled for legacy machines.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/target/i386/
Remove generic non-intel check while validating hyperthreading support.
Certain AMD CPUs can support hyperthreading now.
CPU family with TOPOEXT feature can support hyperthreading now.
Signed-off-by: Babu Moger
Tested-by: Geoffrey McRae
Reviewed-by: Eduardo Habkost
---
target/i386/cpu.c | 17
If the CPU model supports topoext feature, enabled the
feature automatically if it can be supported.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 40
1 file changed, 40 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4dd9a82..
Add support for cpuid leaf CPUID_8000_001E. Build the config that closely
match the underlying hardware. Please refer to the Processor Programming
Reference (PPR) for AMD Family 17h Model for more details.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 86 +
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Friday, June 8, 2018 2:50 PM
> To: Moger, Babu
> Cc: ge...@hostfission.com; k...@vger.kernel.org; m...@redhat.com;
> k...@tripleback.net; mtosa...@redhat.com; xiaoguangr...@tencent.com;
> qemu-devel@nongnu
It seems to me that no one has really looked into the matter, I can't
find any comments,that this issue has been worked on.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1463812
Title:
qemu-system-
On Fri, Jun 8, 2018 at 7:25 PM, Marc-André Lureau
wrote:
> Hi
>
> On Mon, Jun 4, 2018 at 11:37 AM, Gerd Hoffmann wrote:
>> On Fri, Jun 01, 2018 at 06:27:48PM +0200, Marc-André Lureau wrote:
>>> Add to virtio-gpu devices a "vhost-user" property. When set, the
>>> associated vhost-user backend is u
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
---
include/qemu/pmem.h | 1 +
Sorry missed dgilbert's comment about RAMBLOCK_FOREACH_MIGRATABLE in previous
revision.
From: Qemu-devel on behalf of
junyan...@gmx.com
Sent: Saturday, June 9, 2018 1:12:31 AM
To: qemu-devel@nongnu.org
Cc: xiaoguangrong.e...@gmail.com; crosthwaite.pe...@gmail.c
On Fri, Jun 08, 2018 at 02:48:10PM +0200, David Hildenbrand wrote:
> I'll be messing with machine hotplug handlers of pc/spapr/s390x in the
> context of
> [PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers
>
> So this is a spin-off of the cleanup patches in the context of hotplug
On 06/08/2018 05:05 PM, Laurent Vivier wrote:
> I'm rebasing some of these patches for seven years now,
> too many years...
>
> It's an RFC because things have changed in QEMU in seven years,
> for instance the VIA has a new implementation (mos6522) introduced
> by Mark Cave-Ayland and I didn't re
401 - 439 of 439 matches
Mail list logo
