David Hildenbrand writes:
>>> +static void realize_event_facility(DeviceState *dev, Error **errp)
>>> +{
>>> +SCLPEventFacility *event_facility = EVENT_FACILITY(dev);
>>> +Error *local_err = NULL;
>>> +
>>> +qdev_realize(DEVICE(&event_facility->quiesce),
>>> + BUS(&eve
21.05.2020 22:21, Eric Blake wrote:
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> Hi folks,
>
> My impression is that we're getting pretty close to a workable
> implementation here with v22 plus respins of patches 5, 6, and 8. We
> also have a matching QEMU series and a proposal for a new i40e
> consumer, as we
Cédric Le Goater writes:
> On 5/20/20 5:43 PM, Markus Armbruster wrote:
>> Cédric Le Goater writes:
>>
>>> On 5/20/20 8:34 AM, Markus Armbruster wrote:
Cédric Le Goater writes:
> The AST2400 and AST2500 SoCs have two MACs but only the first MAC0 is
> active on the Aspeed mach
21.05.2020 22:21, Eric Blake wrote:
The next patch will add another client that wants to merge dirty
bitmaps; it will be easier to refactor the code to construct the QAPI
struct correctly into a helper function.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best rega
As described by Edgar here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg605124.html
we can use the Ubuntu kernel for testing the xlnx-versal-virt machine.
So let's add a boot test for this now.
Signed-off-by: Thomas Huth
---
tests/acceptance/boot_linux_console.py | 24 ++
On 24/05/2020 18.45, Philippe Mathieu-Daudé wrote:
> Replace some debug printf() calls by qemu_log_mask(LOG_GUEST_ERROR).
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/dma/puv3_dma.c | 9 +++--
> hw/gpio/puv3_gpio.c | 15 +++
> hw/intc/puv3_intc.c | 9 +++--
> hw/m
21.05.2020 22:21, Eric Blake wrote:
Make it easier to copy all the persistent bitmaps of (the top layer
of) a source image along with its guest-visible contents, by adding a
boolean flag for use with qemu-img convert. This is basically
shorthand, as the same effect could be accomplished with a s
Hi all,
as requested by Michael, find below the current version of the Inter-VM
Shared Memory device specification version 2 (as version 1 could be
considered what is currently in QEMU).
This posting is intended to collect feedback from the virtio community
before officially proposing it to be
Signed-off-by: Andreas Schwab
---
linux-user/generic/fcntl.h | 4
linux-user/syscall.c | 6 ++
2 files changed, 10 insertions(+)
diff --git a/linux-user/generic/fcntl.h b/linux-user/generic/fcntl.h
index 9f727d4df2..c85c5b9fed 100644
--- a/linux-user/generic/fcntl.h
+++ b/linux-us
Public bug reported:
This is in reference to
https://github.com/multiarch/qemu-user-static/issues/108.
I am facing issue while installing docker inside s390x container under qemu on
Ubuntu 18.04 host running on amd64.
Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel hos
On Tue, May 19, 2020 at 06:11:32PM +0100, Stefan Hajnoczi wrote:
> A lot of CPU time is spent simply locking/unlocking q->lock during
> polling. Check for completion outside the lock to make q->lock disappear
> from the profile.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block/nvme.c | 12 ++
On Tue, May 19, 2020 at 06:11:33PM +0100, Stefan Hajnoczi wrote:
> nvme_process_completion() explicitly checks cid so the assertion that
> follows is always true:
>
> if (cid == 0 || cid > NVME_QUEUE_SIZE) {
> ...
> continue;
> }
> assert(cid <= NVME_QUEUE_SIZE);
>
> Signed-off-
On Tue, May 19, 2020 at 06:11:35PM +0100, Stefan Hajnoczi wrote:
> There are three issues with the current NVMeRequest->busy field:
> 1. The busy field is accidentally accessed outside q->lock when request
>submission fails.
> 2. Waiters on free_req_queue are not woken when a request is returne
On Tue, May 19, 2020 at 06:11:34PM +0100, Stefan Hajnoczi wrote:
> Do not access a CQE after incrementing q->cq.head and releasing q->lock.
> It is unlikely that this causes problems in practice but it's a latent
> bug.
>
> The reason why it should be safe at the moment is that completion
> proces
On Tue, May 19, 2020 at 06:11:36PM +0100, Stefan Hajnoczi wrote:
> Existing users access free_req_queue under q->lock. Document this.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block/nvme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Sergio Lopez
signature.asc
Descri
Peter Xu writes:
> Sometimes it would be good to be able to read the pin number along
> with the IRQ number allocated. Since we'll dump the IRQ number, no
> reason to not dump the pin information. For example, the vfio-pci
> device will overwrite the pin with the hardware pin number. It would
On May 18 07:02, Klaus Jensen wrote:
> On May 14 06:45, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > First, since the device only supports MSI-X or pin-based interrupt, if
> > MSI-X is not enabled, it should not accept interrupt vectors different
> > from 0 when creating completion queues.
On Tue, May 19, 2020 at 06:11:37PM +0100, Stefan Hajnoczi wrote:
> Passing around both BDRVNVMeState and NVMeQueuePair is unwiedly. Reduce
> the number of function arguments by keeping the BDRVNVMeState pointer in
> NVMeQueuePair. This will come in handly when a BH is introduced in a
> later patch
On 25/05/20 09:01, Markus Armbruster wrote:
>> Just remembered that we fail creating the machine and therefore abort. So
>> not necessary :)
> True.
>
> But let's review briefly what happens when a realize method fails.
>
> In theory, realize fails cleanly, i.e. doing nothing. Another attempt
>
On Tue, May 19, 2020 at 06:11:38PM +0100, Stefan Hajnoczi wrote:
> QEMU block drivers are supposed to support aio_poll() from I/O
> completion callback functions. This means completion processing must be
> re-entrant.
>
> The standard approach is to schedule a BH during completion processing
> and
On Mon, May 25, 2020 at 11:31:16AM +0800, Jason Wang wrote:
>
> On 2020/5/20 下午11:53, Dima Stepanov wrote:
> >A socket write during vhost-user communication may trigger a disconnect
> >event, calling vhost_user_blk_disconnect() and clearing all the
> >vhost_dev structures holding data that vhost-u
On 22/05/2020 19.10, Claudio Fontana wrote:
> move the vcpu throttling functionality into its own module.
>
> This functionality is not specific to any accelerator,
> and it is used currently by migration to slow down guests to try to
> have migrations converge, and by the cocoa MacOS UI to thrott
E.g., with "pc-q35-4.2", trying to coldplug a virtio-pmem-pci devices
results in
"virtio-pmem-pci not supported on this bus"
Reasons is, that the bus does not support hotplug and, therefore, does
not have a hotplug handler. Let's allow coldplugging virtio-pmem devices
on such buses. The hotplu
On Mon, May 25, 2020 at 12:00:10AM -0400, Raphael Norwitz wrote:
> I'm mostly happy with this. A couple comments.
>
> On Wed, May 20, 2020 at 11:54 AM Dima Stepanov
> wrote:
> >
> > A socket write during vhost-user communication may trigger a disconnect
> > event, calling vhost_user_blk_disconne
"Dr. David Alan Gilbert" writes:
> * Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
>> On 5/20/20 5:11 PM, Dr. David Alan Gilbert (git) wrote:
>> > From: "Dr. David Alan Gilbert"
>> >
>> > Simplify qom_set by making it use qmp_qom_set and the JSON parser.
>> >
>> > Note that qom-set like
On Wed, May 20, 2020 at 06:53:13PM +0300, Dima Stepanov wrote:
> A socket write during vhost-user communication may trigger a disconnect
> event, calling vhost_user_blk_disconnect() and clearing all the
> vhost_dev structures holding data that vhost-user functions expect to
> remain valid to roll b
On 20/05/2020 11:07, Igor Mammedow wrote:
> On Thu, 14 May 2020 14:13:11 +0200
> Philippe Mathieu-Daudé wrote:
>
>> On 5/14/20 12:09 PM, Igor Mammedov wrote:
>>> On Sun, 10 May 2020 13:35:05 +0200
>>> Philippe Mathieu-Daudé wrote:
>>>
Since commit 82b911aaff3, machine_run_board_init() c
"Dr. David Alan Gilbert (git)" writes:
> From: "Dr. David Alan Gilbert"
>
> This started off as Andreas Färber's implementation from
> March 2015, but after feedback from Paolo and Markus it morphed into
> using the json output which handles structs reasonably.
>
> Use with qom-list to find the
On 24/05/2020 14:40, Peter Maydell wrote:
> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé
> wrote:
>> It looks to me a normal behavior for a DMA device. DMA devices have a
>> different address space view than the CPUs.
>> Also note the fw_cfg is a generic device, not restricted to the x86
On 24/05/2020 17:51, Philippe Mathieu-Daudé wrote:
> Convert NVR_DPRINTF() to trace events and remove ifdef'ry.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/nvram/mac_nvram.c | 17 +++--
> hw/nvram/trace-events | 4
> 2 files changed, 7 insertions(+), 14 deletions(-)
On 24/05/2020 18:00, Philippe Mathieu-Daudé wrote:
> Convert DPRINTF() to trace events and remove ifdef'ry.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/display/cg3.c| 14 --
> hw/display/trace-events | 4
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
Public bug reported:
libFuzzer found:
qxl-0: guest bug: qxl_add_memslot: guest_start > guest_end 0x >
0x3ff
qemu-fuzz-i386: hw/display/qxl.c:1611: void qxl_set_mode(PCIQXLDevice *,
unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0'
failed.
==8134==
Hello Thomas,
thanks for looking at this,
On 5/25/20 10:44 AM, Thomas Huth wrote:
> On 22/05/2020 19.10, Claudio Fontana wrote:
>> move the vcpu throttling functionality into its own module.
>>
>> This functionality is not specific to any accelerator,
>> and it is used currently by migration to s
On 4/2/20 12:51 PM, Greg Kurz wrote:
> On Wed, 1 Apr 2020 18:46:53 +0200
> Cédric Le Goater wrote:
>
>> The trigger message coming from a HW source contains a special bit
>> informing the XIVE interrupt controller that the PQ bits have been
>> checked at the source or not. Depending on the value
> E.g., with "pc-q35-4.2", trying to coldplug a virtio-pmem-pci devices
> results in
> "virtio-pmem-pci not supported on this bus"
>
> Reasons is, that the bus does not support hotplug and, therefore, does
> not have a hotplug handler. Let's allow coldplugging virtio-pmem devices
> on such buse
Like for read/write in a previous commit, drop extra indirection layer,
generate directly bdrv_readv_vmstate() and bdrv_writev_vmstate().
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/coroutines.h| 10 +++
include/block/block.h | 6 ++--
block/io.c| 67 ++
Hi all!
The aim of the series is to reduce code-duplication and writing
parameters structure-packing by hand around coroutine function wrappers.
It's an alternative to "[PATCH v3] block: Factor out bdrv_run_co()"
patch.
Benefits:
- no code duplication
- less indirection
v4:
01: wording in com
We are going to keep coroutine-wrappers code (structure-packing
parameters, BDRV_POLL wrapper functions) in a separate auto-generated
files. So, we'll need a header with declaration of original _co_
functions, for those which are static now. As well, we'll need
declarations for wrapper functions. D
Most of our coroutine wrappers already follow this convention:
We have 'coroutine_fn bdrv_co_()' as
the core function, and a wrapper 'bdrv_()' which does a polling loop.
The only outsiders are the bdrv_prwv_co and
bdrv_common_block_status_above wrappers. Let's refactor them to behave
as the other
On 25/05/20 08:38, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 20/05/20 17:02, Markus Armbruster wrote:
>
> qdev_realize_and_unref() remains restricted, because its reference
> counting would become rather confusing for bus-less devices.
I think it would be fine, you
We have a very frequent pattern of creating coroutine from function
with several arguments:
- create structure to pack parameters
- create _entry function to call original function taking parameters
from struct
- do different magic to handle completion: set ret to NOT_DONE or
EINPROG
On 5/19/20 11:48 AM, Greg Kurz wrote:
> On Wed, 13 May 2020 17:11:05 +0200
> Cédric Le Goater wrote:
>
>> The XIVE2 interrupt controller of the POWER10 processor follows the
>> same logic than on POWER9 but the HW interface has been largely
>> reviewed. It has a new register interface, different
Now, when we are not more paying extra code for coroutine wrappers,
there no more sence in extra indirection layer: bdrv_prwv(). Let's drop
it and instead genereate pure bdrv_preadv() and bdrv_pwritev().
Currently, bdrv_pwritev() and bdrv_preadv() are returning bytes on
success, auto generated fun
On 5/20/20 3:46 PM, Greg Kurz wrote:
> I guess you mean POWER10 ?
Yes :/
Thanks,
C.
>
> On Wed, 13 May 2020 17:11:08 +0200
> Cédric Le Goater wrote:
>
>> PHB4 and PHB5 are very similar. Use the PHB4 models with some minor
>> adjustements in a subclass for P10.
>>
>> Signed-off-by: Cédric L
On 25/05/20 03:18, Yan Zhao wrote:
> On Thu, May 21, 2020 at 04:38:47PM +0200, Paolo Bonzini wrote:
>> On 30/04/20 11:40, Peter Maydell wrote:
This does not "drop" a write to a r/o region -- it causes it to generate
whatever the guest architecture's equivalent of a bus error is (eg data
>
On 25/05/20 07:44, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 08/05/20 12:49, Markus Armbruster wrote:
>>> Fixes: abc9bf69a66a11499a801ff545b8fe7adbb3a04c
>>> Fixes: Coverity CID 1428754
>>> Signed-off-by: Markus Armbruster
>>> ---
>>> cpus.c | 2 +-
>>> 1 file changed, 1 insertio
s/encrption/encryption
On Thu, 21 May 2020 13:42:57 +1000
David Gibson wrote:
> At the moment AMD SEV sets a special function pointer, plus an opaque
> handle in KVMState to let things know how to encrypt guest memory.
>
> Now that we have a QOM interface for handling things related to guest
On Thu, 21 May 2020 13:42:56 +1000
David Gibson wrote:
> Several architectures have mechanisms which are designed to protect guest
> memory from interference or eavesdropping by a compromised hypervisor. AMD
> SEV does this with in-chip memory encryption and Intel has a similar
> mechanism. POW
On 5/18/20 4:31 PM, Collin Walling wrote:
> On 5/18/20 4:55 AM, Janosch Frank wrote:
>> On 5/16/20 12:20 AM, Collin Walling wrote:
>>> As more features and facilities are added to the Read SCP Info (RSCPI)
>>> response, more space is required to store them. The space used to store
>>> these new fea
On 5/19/20 3:19 PM, Cornelia Huck wrote:
> On Mon, 18 May 2020 11:15:07 -0400
> Collin Walling wrote:
>
>> On 5/18/20 4:50 AM, Janosch Frank wrote:
>>> On 5/16/20 12:20 AM, Collin Walling wrote:
Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowin
On 5/25/20 12:20 PM, Paolo Bonzini wrote:
> On 25/05/20 03:18, Yan Zhao wrote:
>> On Thu, May 21, 2020 at 04:38:47PM +0200, Paolo Bonzini wrote:
>>> On 30/04/20 11:40, Peter Maydell wrote:
> This does not "drop" a write to a r/o region -- it causes it to generate
> whatever the guest archit
Sorry Philippe I missed that.
Would be happy to do a PR if needed but:
* I never did that.
* Looking at https://wiki.qemu.org/Contribute/SubmitAPullRequest, I don't have
the signed GPG key either.
Cheers,
Fred
Le 5/23/20 à 7:26 PM, Philippe Mathieu-Daudé a écrit :
ping?
On 5/11/20 9:0
On Wed, May 20, 2020 at 03:25:53PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Gerd,
>
> On 5/20/20 3:19 PM, Gerd Hoffmann wrote:
> > qboot isn't a bios and shouldnt be named that way.
>
> Still it resides in a directory named pc-bios =)
Yep, that should be named "firmware" but changing that is b
On 25/05/20 12:54, Philippe Mathieu-Daudé wrote:
>> Not all of them, only those that need to return MEMTX_ERROR. I would
>> like some guidance from Peter as to whether (or when) reads from ROMs
>> should return MEMTX_ERROR. This way, we can use that information to
>> device what the read-only ra
The ADC region size is 256B, split as:
- [0x00 - 0x4f] defined
- [0x50 - 0xff] reserved
All registers are 32-bit (thus when the datasheet mentions the
last defined register is 0x4c, it means its address range is
0x4c .. 0x4f.
This model implementation is also 32-bit. Set MemoryRegionOps
'impl'
On 5/25/20 1:08 PM, Philippe Mathieu-Daudé wrote:
> The ADC region size is 256B, split as:
> - [0x00 - 0x4f] defined
> - [0x50 - 0xff] reserved
>
> All registers are 32-bit (thus when the datasheet mentions the
> last defined register is 0x4c, it means its address range is
> 0x4c .. 0x4f.
>
> T
The ADC region size is 256B, split as:
- [0x00 - 0x4f] defined
- [0x50 - 0xff] reserved
All registers are 32-bit (thus when the datasheet mentions the
last defined register is 0x4c, it means its address range is
0x4c .. 0x4f.
This model implementation is also 32-bit. Set MemoryRegionOps
'impl'
On Thu, 21 May 2020 13:43:03 +1000
David Gibson wrote:
> Some upcoming POWER machines have a system called PEF (Protected
> Execution Framework) which uses a small ultravisor to allow guests to
s/Framework/Facility
> run in a way that they can't be eavesdropped by the hypervisor. The
> effect
On 5/20/20 4:22 PM, Greg Kurz wrote:
> On Wed, 13 May 2020 17:11:06 +0200
> Cédric Le Goater wrote:
>
>> Needs some more refinements but this model does not do much anyhow.
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> include/hw/ppc/pnv.h | 1 +
>> include/hw/ppc/pnv_occ.h | 2 ++
>
Add the ability to store encryption keys in the Linux keyring
facility.
For that, factor out common parts from secret to a new abstract class
secret_common, and introduce new user-creatable secret_keyring class
inheriting from it.
Use '--enable-keyring/--disable-keyring' configuration parameters
t
Create base class 'common secret'. Move common data and logic from
'secret' to 'common_secret' class. This allowed adding abstraction layer
for easier adding new 'secret' objects in future.
Convert 'secret' class to child from basic 'secret_common' with 'data'
and 'file' properties.
Signed-off-by:
Console interaction in avocado scripts was possible only with single
default VM.
This patch modifies the function parameters to allow passing a specific
VM as a parameter to interact with it.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/avocado_qemu/__init__.py | 12 +++-
1 file
This patch adds a test for record/replay an execution of x86_64 machine.
Execution scenario includes simple kernel boot, which allows testing
basic hardware interaction in RR mode.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 16
1 file changed, 16 in
The following series adds record/replay tests to the acceptance group.
Test pass successfully with the latest submitted record/replay fixes:
- replay: notify the main loop when there are no instructions
- replay: synchronize on every virtual timer callback
The provided tests perform kernel boot
Add tests:
test_secret_keyring_good;
test_secret_keyring_revoked_key;
test_secret_keyring_expired_key;
test_secret_keyring_bad_serial_key;
test_secret_keyring_bad_key_access_right;
Added tests require libkeyutils. The absence of this library is not
critical, because these tests will be s
This patch adds a base for testing kernel boot recording and replaying.
Each test has the phase of recording and phase of replaying.
Virtual machines just boot the kernel and do not interact with
the network.
Structure and image links for the tests are borrowed from boot_linux_console.py
Testing co
This patch adds a test for record/replay of the kernel
image boot for aarch64 platform.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/acceptance/replay_kernel.py
b/tests/acceptance/replay_kern
Add the ability for the secret object to obtain secret data from the
Linux in-kernel key managment and retention facility, as an extra option
to the existing ones: reading from a file or passing directly as a
string.
The secret is identified by the key serial number. The upper layers
need to insta
This patch adds a test for record/replay of the kernel
image boot for m68k platform.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/acceptance/replay_kernel.py
b/tests/acceptance/replay_kernel.
Use qemu_log_mask(LOG_GUEST_ERROR),
let the device be parent of a MemoryRegion.
Philippe Mathieu-Daudé (3):
MAINTAINERS: Cover vmware_vga related files in VMware section
hw/display/vmware_vga: Replace printf() calls by qemu_log_mask(ERROR)
hw/display/vmware_vga: Let the PCI device own its I/
This patch adds a test for record/replay of the kernel
image boot for two different arm platforms.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 46 +
1 file changed, 46 insertions(+)
diff --git a/tests/acceptance/replay_kernel.py
To avoid the orphan I/O memory region being added in the /unattached
QOM container, register the PCI device as its owner.
Signed-off-by: Philippe Mathieu-Daudé
---
RFC: This might break migration
---
hw/display/vmware_vga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/d
This patch adds a test for record/replay of the kernel
image boot for ppc64 platform.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tests/acceptance/replay_kernel.py
b/tests/acceptance/replay_kernel.py
Add the VMware VGA display and its ROM files to the VMware section.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3690f313c3..2da00ce798 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1776,9 +1776,12 @
This patch adds more record/replay tests with kernel images.
Signed-off-by: Pavel Dovgalyuk
---
tests/acceptance/replay_kernel.py | 80 +
1 file changed, 80 insertions(+)
diff --git a/tests/acceptance/replay_kernel.py
b/tests/acceptance/replay_kernel.py
in
Avoid flooding stdio by converting printf() calls to
qemu_log_mask(GUEST_ERROR), which are disabled by default.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/vmware_vga.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/hw/display/vmware_vga.c b/hw/dis
On 5/20/20 4:44 PM, Greg Kurz wrote:
> On Wed, 13 May 2020 17:11:07 +0200
> Cédric Le Goater wrote:
>
>> Still needs some refinements on the XSCOM registers.
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> include/hw/ppc/pnv.h | 4
>> hw/ppc/pnv.c | 33
This patch adds a test for record/replay, which boots Linux
image from the disk and interacts with the network.
The idea and code of this test is borrowed from boot_linux.py
However, currently record/replay works only for x86_64,
therefore other tests were excluded.
Each test consists of the follo
Convert DPRINTF() to trace events and remove ifdef'ry.
Signed-off-by: Philippe Mathieu-Daudé
---
v2: Order addr/val/size (Mark review)
---
hw/display/cg3.c| 14 --
hw/display/trace-events | 4
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/hw/display/cg
hw_error() calls exit(). This a bit overkill when we can log
the accesses as unimplemented or guest error.
When fuzzing the devices, we don't want the whole process to
exit. Replace some hw_error() calls by qemu_log_mask()
(missed in commit 5a0001ec7e).
Signed-off-by: Philippe Mathieu-Daudé
---
On 5/20/20 6:40 PM, Greg Kurz wrote:
> On Wed, 13 May 2020 17:11:03 +0200
> Cédric Le Goater wrote:
>
>> The XIVE2 interrupt controller of the POWER10 processor follows the
>> same logic than on POWER9 but the HW interface has been largely
>> reviewed. The interrupt controller has a new register
Replace printf() calls by qemu_log_mask(), which is disabled
by default. This avoid flooding the terminal when fuzzing the
device.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/pxa2xx.c | 66 ++---
hw/display/pxa2xx_lcd.c | 26
2 fi
Last pair of trivial logging cleanup patches
from last week-end.
Philippe Mathieu-Daudé (2):
hw/input/pxa2xx_keypad: Replace hw_error() by qemu_log_mask()
hw/arm/pxa2xx: Replace printf() call by qemu_log_mask()
hw/arm/pxa2xx.c | 66 +---
hw/displa
On Thu, May 21, 2020 at 11:29:21AM +0200, Igor Mammedov wrote:
> On Wed, 20 May 2020 15:19:55 +0200
> Gerd Hoffmann wrote:
>
> > Looks like the logiv was copied over from q35.
> >
> > q35 does this for backward compatibility, there is no reason to do this
> > on microvm though. So split @ 2G un
Hi,
> > -#define VIRTIO_IRQ_BASE 5
> > +mms->virtio_irq_base = 8;
>
> Hmm you made it runtime configurable indeed, but you also changed it from 5
> to 8. Worth a different patch, or at least mentioning in commit description.
Oops, that wasn't intentional. I'll change it back to 5.
On 5/21/20 7:47 AM, Thomas Huth wrote:
> On 21/05/2020 07.44, Thomas Huth wrote:
>> On 14/05/2020 14.37, Janosch Frank wrote:
>>> ZMODE has a lot of ambiguity with the ESAME architecture mode, but is
>>> actually 64 bit addressing.
>>>
>>> Signed-off-by: Janosch Frank
>>> Reviewed-by: Pierre Morel
On 5/21/20 7:50 AM, Thomas Huth wrote:
> On 14/05/2020 14.37, Janosch Frank wrote:
>> Let's move some of the PSW mask defines into s390-arch.h and use them
>> in jump2ipl.c
>>
>> Signed-off-by: Janosch Frank
>> Reviewed-by: David Hildenbrand
>> ---
>> pc-bios/s390-ccw/jump2ipl.c | 10 --
On 5/20/20 7:17 PM, Greg Kurz wrote:
> On Wed, 13 May 2020 17:11:04 +0200
> Cédric Le Goater wrote:
>
>> The VP space is larger in XIVE2 (P10), 24 bits instead of 19bits on
>> XIVE (P9), and the CAM line can use a 7bits or 8bits thread id.
>>
>> For now, we only use 7bits thread ids, same as P9,
On Thu, May 21, 2020 at 12:36:24PM +0200, Igor Mammedov wrote:
> On Wed, 20 May 2020 15:20:03 +0200
> Gerd Hoffmann wrote:
>
> > Signed-off-by: Gerd Hoffmann
> > ---
> > hw/i386/microvm.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
>
On 5/20/20 9:53 PM, Thomas Huth wrote:
> On 14/05/2020 14.37, Janosch Frank wrote:
>> Let's consolidate timing related functions into one header.
>>
>> Signed-off-by: Janosch Frank
>> ---
>> pc-bios/s390-ccw/menu.c| 1 +
>> pc-bios/s390-ccw/netmain.c | 15 +++--
>> pc-bios/s3
libFuzzer found using 'qemu-system-i386 -M q35':
qemu: hardware error: e1000e: PSRCTL.BSIZE0 cannot be zero
CPU #0:
EAX= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =
On 5/25/20 1:02 PM, Gerd Hoffmann wrote:
> On Wed, May 20, 2020 at 03:25:53PM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Gerd,
>>
>> On 5/20/20 3:19 PM, Gerd Hoffmann wrote:
>>> qboot isn't a bios and shouldnt be named that way.
>>
>> Still it resides in a directory named pc-bios =)
>
> Yep, that
On 5/25/20 1:49 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> -#define VIRTIO_IRQ_BASE 5
>
>>> +mms->virtio_irq_base = 8;
>>
>> Hmm you made it runtime configurable indeed, but you also changed it from 5
>> to 8. Worth a different patch, or at least mentioning in commit description.
>
> Oops,
On 25/05/20 07:50, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On Mon, 18 May 2020 at 06:04, Markus Armbruster wrote:
>>> These devices are optional, and enabled by property "enable-bitband".
>>> armv7m_instance_init() creates them unconditionally, because the
>>> property has not been
On Mon, 25 May 2020 at 13:32, Paolo Bonzini wrote:
>
> On 25/05/20 07:50, Markus Armbruster wrote:
> > Peter Maydell writes:
> >
> >> On Mon, 18 May 2020 at 06:04, Markus Armbruster wrote:
> >>> These devices are optional, and enabled by property "enable-bitband".
> >>> armv7m_instance_init() cr
On 5/25/20 9:26 AM, Thomas Huth wrote:
> As described by Edgar here:
>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg605124.html
>
> we can use the Ubuntu kernel for testing the xlnx-versal-virt machine.
> So let's add a boot test for this now.
>
> Signed-off-by: Thomas Huth
> ---
>
Patchew URL:
https://patchew.org/QEMU/20200525100801.13859-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEG
Initially, I was the only one who was using Gitlab while most developers
had their git trees still on other systems, but that has changed nowadays.
There is now much more interest in the Gitlab-CI today, so it would be
good to have more than only one maintainer / reviewer for the gitlab-ci.yml
file
Currently all pipelines of the gitlab CI are failing, except for the
"build-user" pipeline. There is an issue with the default container
image (likely Debian stable) where they imported something bad in one
of the system headers:
/usr/include/linux/swab.h: In function '__swab':
/builds/huth/qemu
1 - 100 of 263 matches
Mail list logo
