Hi All:
I have 2 questions about (un)hotplug on pcie-root-port.
First Question (hotplug failure because of redundant PCI_EXP_LNKSTA_DLLLA bit
set):
during VM boot, qemu sets PCI_EXP_LNKSTA_DLLLA according to this process:
pcie_cap_init() -> pcie_cap_v1_fill(),
even if there's no
On 7/18/19 5:26 AM, Paolo Bonzini wrote:
> On 18/07/19 11:17, Philippe Mathieu-Daudé wrote:
>> The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
>> PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
>> TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be created
>> in
On 7/15/19 12:06 PM, Andrey Shinkevich wrote:
> The Valgrind tool reports about the uninitialised buffer 'buf'
> instantiated on the stack of the function guess_disk_lchs().
> Pass 'read-zeroes=on' to the null block driver to make it deterministic.
> The output of the tests 051, 186 and 227 now
On 7/18/19 8:38 PM, Laszlo Ersek wrote:
> On 07/18/19 17:03, Laszlo Ersek wrote:
>> On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
>>> To avoid incoherent states when the machine resets (see but report
>>
>> (1) For the PULL request, please fix the typo: s/but/bug/
>>
>>> below), add the device
On 07/18/19 17:03, Laszlo Ersek wrote:
> On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
>> To avoid incoherent states when the machine resets (see but report
>
> (1) For the PULL request, please fix the typo: s/but/bug/
>
>> below), add the device reset callback.
>>
>> A "system reset" sets
On 7/18/19 6:20 AM, no-re...@patchew.org wrote:
> PASS 17 test-bdrv-drain /bdrv-drain/graph-change/drain_all
> =
> ==10263==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6122c1f0 at pc 0x555fd5bd7cb6 bp
Evgeny Yakovlev
Lead Software Engineer, Yandex.Cloud Hypervisor Team
On 18.07.2019 17:59, Kevin Wolf wrote:
Am 18.07.2019 um 15:52 hat Евгений Яковлев geschrieben:
Hi everyone,
My previous message was misformatted, so here's another one. Sorry about
that.
We're currently working on
On 07/18/19 12:48, Philippe Mathieu-Daudé wrote:
> To avoid incoherent states when the machine resets (see but report
(1) For the PULL request, please fix the typo: s/but/bug/
> below), add the device reset callback.
>
> A "system reset" sets the device state machine in READ_ARRAY mode
> and,
Am 18.07.2019 um 15:52 hat Евгений Яковлев geschrieben:
> Hi everyone,
>
> My previous message was misformatted, so here's another one. Sorry about
> that.
>
> We're currently working on implementing a qemu BDRV format driver which we
> are using with virtio-blk devices.
>
> I have a question
Hi everyone,
My previous message was misformatted, so here's another one. Sorry about
that.
We're currently working on implementing a qemu BDRV format driver which
we are using with virtio-blk devices.
I have a question concerning BDRV request fragmentation and virtio-blk
write request
Hi everyone,
We're currently working on implementing a qemu BDRV format driver which
we are using with virtio-blk devices.
I have a question concerning BDRV request fragmentation and virtio-blk
write request submission which is not entirely clear to me by only
reading virtio spec. Could you
Am 18.07.2019 um 11:26 hat Paolo Bonzini geschrieben:
> On 18/07/19 11:17, Philippe Mathieu-Daudé wrote:
> > The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
> > PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
> > TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be
The pflash device lacks a reset() function.
When a machine is resetted, the flash might be in an
inconsistent state, leading to unexpected behavior.
Resolve this issue by adding a DeviceReset() handler.
v7: Surgical bugfix, do not attempt to improve the model in any
way, thus ignoring all
To avoid incoherent states when the machine resets (see but report
below), add the device reset callback.
A "system reset" sets the device state machine in READ_ARRAY mode
and, after some delay, set the SR.7 READY bit.
Since we do not model timings, we set the SR.7 bit directly.
Fixes:
Patchew URL: https://patchew.org/QEMU/20190717173937.18747-1-js...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make
On 17/07/19 23:27, Dmitry Fomichev wrote:
> diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
> index a43efe39ec..e38d3160fa 100644
> --- a/hw/scsi/scsi-generic.c
> +++ b/hw/scsi/scsi-generic.c
> @@ -238,6 +238,7 @@ static void scsi_read_complete(void * opaque, int ret)
>
On 18/07/19 11:17, Philippe Mathieu-Daudé wrote:
> The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
> PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
> TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be created
> in part, it has to be created and used as a whole.
>
>
The 'piix3-ide' (and 'piix3-ide-xen') devices are part of the
PIIX3 chipset modelled as TYPE_PIIX3_PCI_DEVICE (respectivelly
TYPE_PIIX3_XEN_DEVICE). The PIIX3 chipset can not be created
in part, it has to be created and used as a whole.
Similarly with the 'piix4-ide' device and the PIIX4 chipset
> -Original Message-
> From: Dmitry Fomichev
> Sent: 17 July 2019 22:27
> To: qemu-de...@nongnu.org; qemu-block@nongnu.org
> Cc: John Snow ; Kevin Wolf ; Max Reitz
> ; Keith
> Busch ; Stefan Hajnoczi ; Michael
> S. Tsirkin
> ; Stefano Stabellini ; Anthony Perard
> ; Paul Durrant ; Paolo
On 16/07/2019 18.12, Max Reitz wrote:
> On 16.07.19 18:09, Eric Blake wrote:
>> On 7/16/19 10:58 AM, Max Reitz wrote:
[...]
Is there any way to create our sockets somewhere under /tmp instead of
inside tests/qemu-iotests, so that we have a shorter filename for
sockets no matter how
20 matches
Mail list logo
