Add a command to query current temperature from all sensors able
to report it:
{ "execute": "query-temperature-sensors" }
{
"return": [
{
"temperature": 25,
"name": "videocore"
},
{
"temperature": 25,
Hi,
This series is part of a bigger one I was preparing for a GSoC
project, but unfortunately no student got interested.
The idea is to allow device with temperature sensors to use a
common API with temperature operations.
While guest are running, you can modify the temperatures to check
the
> From: Yan Zhao
> Sent: Tuesday, April 21, 2020 10:37 AM
>
> On Tue, Apr 21, 2020 at 06:56:00AM +0800, Alex Williamson wrote:
> > On Sun, 19 Apr 2020 21:24:57 -0400
> > Yan Zhao wrote:
> >
> > > On Fri, Apr 17, 2020 at 07:24:57PM +0800, Cornelia Huck wrote:
> > > > On Fri, 17 Apr 2020 05:52:02
21.04.2020 11:11, Denis Plotnikov wrote:
The test checks fulfilling qcow2 requirements for the compression
type feature and zstd compression type operability.
Signed-off-by: Denis Plotnikov
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
On Wed, 2020-04-15 at 15:01 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Signed-off-by: Klaus Jensen
> Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/block/nvme.c | 7 ++-
> hw/block/nvme.h | 2 --
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/hw/block/nvme.c
* Andrey Shinkevich (andrey.shinkev...@virtuozzo.com) wrote:
> Provide the possibility to pass the 'filter-node-name' parameter to the
> block-stream job as it is done for the commit block job.
>
> Signed-off-by: Andrey Shinkevich
> ---
> block/stream.c| 5 +++--
> blockdev.c
Hi,
thanks for the patch, I tested it in my setup and I'm seeing numbers
that make sense.
However, I can create a setup which places the value 02h* into the
ApicIdSize field, which is reserved. However, I deem this a
configuration issue as well.
* -cpu EPYC-v2 -smp 4,cores=4 -->
20.04.2020 16:32, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/274 | 152
tests/qemu-iotests/274.out | 202
20.04.2020 16:32, Kevin Wolf wrote:
This changes the output of some files where instead of filter_img_info()
now filter_testfiles() takes precedence, so update the reference output.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/iotests.py | 5 -
tests/qemu-iotests/206.out| 12
On Tue, Apr 21, 2020 at 10:25:49AM +0100, Peter Maydell wrote:
> On Tue, 21 Apr 2020 at 10:16, Gerd Hoffmann wrote:
> > cirrus stopped using pointers years ago, exactly for the reasons
> > outlined above. Conversion was pretty straight forward.
> >
> > commit
20.04.2020 16:32, Kevin Wolf wrote:
When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
Consider the following scenario where the overlay is
21.04.2020 13:50, Alberto Garcia wrote:
On Tue 21 Apr 2020 10:47:17 AM CEST, Vladimir Sementsov-Ogievskiy
wrote:
+if ((flags & BDRV_REQ_ZERO_WRITE) && offset > old_length) {
+ret = qcow2_cluster_zeroize(bs, old_length, offset - old_length, 0);
Hmm. As I understand,
20.04.2020 16:32, Kevin Wolf wrote:
For regular files, we always get BDRV_REQ_ZERO_WRITE behaviour from the
OS, so we can advertise the flag and just ignore it.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
On Tue, 21 Apr 2020 at 11:22, Marc-André Lureau
wrote:
>
> Hi
>
> On Tue, Apr 21, 2020 at 11:18 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi Samuel and Marc-André,
> >
> > Peter is going to tag 5.0-rc4 (final before release) today.
> > Do you have plans to send a last minute pull-request to fix
On Tue 21 Apr 2020 10:47:17 AM CEST, Vladimir Sementsov-Ogievskiy
wrote:
>> +if ((flags & BDRV_REQ_ZERO_WRITE) && offset > old_length) {
>> +ret = qcow2_cluster_zeroize(bs, old_length, offset - old_length, 0);
>
> Hmm. As I understand, qcow2_cluster_zeroize is unprepared to
>
Philippe Mathieu-Daudé writes:
> These scripts are loaded as plugin by GDB (and they don't
> have any __main__ entry point). Remove the shebang header.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Alex Bennée
> ---
> scripts/qemugdb/__init__.py | 3 +--
> scripts/qemugdb/aio.py
On Tue, Apr 21, 2020 at 11:43:36AM +0200, Paolo Bonzini wrote:
> On 21/04/20 01:31, Peter Xu wrote:
> >>
> >> However, instead of memory_region_transaction_commit,
> >> memory_region_finalize probably should do something like
> >>
> >> --memory_region_transaction_depth;
> >> assert
Philippe Mathieu-Daudé writes:
> Keep an eye on these "same same, but different" files.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: "Alex Bennée"
Acked-by: Alex Bennée
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On Tue 21 Apr 2020 10:11:14 AM CEST, Denis Plotnikov
wrote:
> The patch adds some preparation parts for incompatible compression type
> feature to qcow2 allowing the use different compression methods for
> image clusters (de)compressing.
>
> It is implied that the compression type is set on the
On Wed, 2020-04-15 at 15:01 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Pull the controller memory buffer check to its own function. The check
> will be used on its own in later patches.
>
> Signed-off-by: Klaus Jensen
> Acked-by: Keith Busch
> Reviewed-by: Philippe Mathieu-Daudé
>
On Tue 21 Apr 2020 07:06:42 AM CEST, Derek Su wrote:
> Hello,
>
> This work is promising and interesting.
> I'd like to try this new feature.
> Could you please export a branch because the patches cannot be applied
> to current master?
Hi,
you can apply v4 on top of
On Tue, Apr 21, 2020 at 12:22 PM Marc-André Lureau
wrote:
>
> Hi
>
> On Tue, Apr 21, 2020 at 11:18 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi Samuel and Marc-André,
> >
> > Peter is going to tag 5.0-rc4 (final before release) today.
> > Do you have plans to send a last minute pull-request to
On Tue, Apr 21, 2020 at 12:22:05PM +0200, Marc-André Lureau wrote:
> Hi
>
> On Tue, Apr 21, 2020 at 11:18 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi Samuel and Marc-André,
> >
> > Peter is going to tag 5.0-rc4 (final before release) today.
> > Do you have plans to send a last minute
Hi
On Tue, Apr 21, 2020 at 11:18 AM Philippe Mathieu-Daudé
wrote:
>
> Hi Samuel and Marc-André,
>
> Peter is going to tag 5.0-rc4 (final before release) today.
> Do you have plans to send a last minute pull-request to fix CVE-2020-1983?
>
>
Thanks Jason, I will fix these problems and send new version soon
On Tue, Apr 21, 2020 at 12:05 PM Jason Wang wrote:
>
> On 2020/4/20 下午5:32, Cindy Lu wrote:
> > vDPA device is a device that uses a datapath which complies with the
> > virtio specifications with vendor specific control path.
Le 4/20/20 à 10:43 PM, Laurent Vivier a écrit :
Le 20/04/2020 à 21:08, KONRAD Frederic a écrit :
Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit :
Le 20/04/2020 à 16:01, frederic.kon...@adacore.com a écrit :
From: KONRAD Frederic
Currently "cf-core.xml" is sent to GDB when using any m68k
On Tue, Apr 21, 2020 at 11:40 AM Jason Wang wrote:
>
> On 2020/4/20 下午5:32, Cindy Lu wrote:
> > This patch set introduces a new net client type: vhost-vdpa.
> > vhost-vdpa net client will set up a vDPA device which is
> svhostdevpecified
>
>
> typo.
>
> Will fix this
>
> > by a "vhostdev"
On 21/04/20 01:31, Peter Xu wrote:
>>
>> However, instead of memory_region_transaction_commit,
>> memory_region_finalize probably should do something like
>>
>> --memory_region_transaction_depth;
>> assert (memory_region_transaction_depth ||
>> (!memory_region_update_pending &&
>>
On Wed, 2020-04-15 at 15:01 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Change the prefix of all nvme device related trace events to 'pci_nvme'
> to not clash with trace events from the nvme block driver.
>
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme.c | 190
Keep an eye on these "same same, but different" files.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: "Alex Bennée"
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8cbc1fac2b..7a7f2b9c31 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2083,6
Trivial Python3 fixes, again...
Philippe Mathieu-Daudé (4):
MAINTAINERS: Cover the GDB Python scripts in the gdbstub section
scripts/qemugdb: Remove shebang header
scripts/qmp: Use Python 3 interpreter
scripts/qmp: Fix QEMU Python scripts path
MAINTAINERS | 1 +
Signed-off-by: Philippe Mathieu-Daudé
---
scripts/qmp/qom-get | 2 +-
scripts/qmp/qom-list | 2 +-
scripts/qmp/qom-set | 2 +-
scripts/qmp/qom-tree | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/qmp/qom-get b/scripts/qmp/qom-get
index 007b4cd442..72ccd79330
These scripts are loaded as plugin by GDB (and they don't
have any __main__ entry point). Remove the shebang header.
Signed-off-by: Philippe Mathieu-Daudé
---
scripts/qemugdb/__init__.py | 3 +--
scripts/qemugdb/aio.py | 3 +--
scripts/qemugdb/coroutine.py | 3 +--
QEMU Python scripts have been moved in commit 8f8fd9edba4 ("Introduce
Python module structure"). Use the same sys.path modification used
in the referenced commit to be able to use these scripts again.
Signed-off-by: Philippe Mathieu-Daudé
---
scripts/qmp/qmp | 4 +++-
scripts/qmp/qom-fuse
On Wed, 2020-04-15 at 15:13 +0200, Philippe Mathieu-Daudé wrote:
> On 4/15/20 3:01 PM, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > The size of the BAR is 0x1000 (main registers) + 8 bytes for each
> > queue. Currently, the size of the BAR is calculated like so:
> >
> > n->reg_size =
On Tue, 21 Apr 2020 at 10:32, Aleksandar Markovic
wrote:
>
> пон, 20. апр 2020. у 23:25 Peter Maydell је
> написао/ла:
> >
> > The kernel has different handling for syscalls with invalid
> > numbers that are in the "arm-specific" range 0x9f and up:
> > * 0x9f..0x9f07ff return -ENOSYS if
пон, 20. апр 2020. у 23:25 Peter Maydell је
написао/ла:
>
> The kernel has different handling for syscalls with invalid
> numbers that are in the "arm-specific" range 0x9f and up:
> * 0x9f..0x9f07ff return -ENOSYS if not implemented
> * other out of range syscalls cause a SIGILL
> (see
On Tue, 21 Apr 2020 at 01:39, David Gibson wrote:
>
> On Mon, Apr 20, 2020 at 07:56:50PM +0100, Peter Maydell wrote:
> > On Fri, 17 Apr 2020 at 10:08, Philippe Mathieu-Daudé
> > wrote:
> > >
> > > This fixes:
> > >
> > > $ qemu-system-ppc64 \
> > > -machine pseries-4.1 -cpu power9 \
> > >
On Tue, 21 Apr 2020 at 10:16, Gerd Hoffmann wrote:
> cirrus stopped using pointers years ago, exactly for the reasons
> outlined above. Conversion was pretty straight forward.
>
> commit 026aeffcb4752054830ba203020ed6eb05bcaba8
> Author: Gerd Hoffmann
> Date: Wed Mar 15 11:47:52 2017 +0100
>
On Wed, Apr 15, 2020 at 07:51:38AM +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> The emulated nvme device (hw/block/nvme.c) is currently using an
> internal Intel device id.
>
> Prepare to change that by allocating a device id under the 1b36 (Red
> Hat, Inc.) vendor id.
>
>
Hi Samuel and Marc-André,
Peter is going to tag 5.0-rc4 (final before release) today.
Do you have plans to send a last minute pull-request to fix CVE-2020-1983?
https://gitlab.freedesktop.org/slirp/libslirp/-/commit/9ac0371bb
Regards,
Phil.
> > > The SM501 datasheet is entirely unhelpful on this question, but
> > > my suggestion is that we should convert the code so that instead
> > > of operating directly on pointers into the middle of the local_mem
> > > buffer all the accesses to local_mem go via functions which mask
> > > off the
On Tue, Apr 21, 2020 at 11:57 AM Jason Wang wrote:
>
> On 2020/4/20 下午5:32, Cindy Lu wrote:
> > Currently we have 2 types of vhost backends in QEMU: vhost kernel and
> > vhost-user. The above patch provides a generic device for vDPA purpose,
> > this vDPA device exposes to user space a
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
In the case of postcopy, relying on used_length is racy as soon as the
guest is running. Also, when
Let's consolidate resetting the variables.
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/ram.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index
Add two new helper functions. This will in come handy once we want to
handle ram block resizes while postcopy is active.
Note that ram_block_from_stream() will already print proper errors.
Reviewed-by: Dr. David Alan Gilbert
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
We never read or write beyond the used_length of memory blocks when
migrating. Make this clearer by using offset_in_ramblock() consistently.
Reviewed-by: Dr. David Alan Gilbert
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/ram.c |
When we partially change mappings (esp., mmap over parts of an existing
mmap like qemu_ram_remap() does) where we have a userfaultfd handler
registered, the handler will implicitly be unregistered from the parts that
changed.
Trying to place pages onto mappings where there is no longer a handler
We want to make use of ram_block_discard_range() in the RAM block resize
callback when growing a RAM block, *before* used_length is changed.
Let's relax the check. We always have a reserved mapping for the whole
max_length, so we cannot corrupt unrelated data.
Reviewed-by: Peter Xu
Cc: Richard
We actually want to print the used_length, against which we check.
Reviewed-by: Dr. David Alan Gilbert
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/multifd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In case we grow our RAM after ram_postcopy_incoming_init() (e.g., when
synchronizing the RAM block state with the migration source), the resized
part would not get discarded. Let's perform that when being notified
about a resize while postcopy has been advised, but is not listening
yet. With
Let's make add/remove optional. We want to introduce a RAM block
notifier for RAM migration, that's only interested in resizes.
Reviewed-by: Peter Xu
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
In the case of precopy, the ram block size must not change on the source,
after syncing the RAM block
Current code no longer needs these stubs to compile. Let's just remove
them.
Reviewed-by: Peter Xu
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
stubs/ram-block.c | 20
1 file changed, 20 deletions(-)
Factor it out into common code when a new notifier is registered, just
as done with the memory region notifier. This allows us to have the
logic about how to process existing ram blocks at a central place (which
will be extended soon).
Just like when adding a new ram block, we have to register
Basically a resend. Who's the lucky winner to pick this up for 5.1? :)
---
This is the follow up of
"[PATCH RFC] memory: Don't allow to resize RAM while migrating" [1]
This series contains some (slightly modified) patches also contained in:
"[PATCH v2 fixed 00/16] Ram blocks with
Ram block notifiers are currently not aware of resizes. Especially to
handle resizes during migration, but also to implement actually resizeable
ram blocks (make everything between used_length and max_length
inaccessible), we want to teach ram block notifiers about resizeable
ram.
Introduce the
On Tue, 21 Apr 2020 at 08:48, Philippe Mathieu-Daudé wrote:
> I couldn't find a git-diff option to display this change in an obvious way.
Yeah, as a human you can say "it would be easier to read
if the '} else {' line was not treated as unchanged", but the
automatic diff output isn't totally
On Tue, 21 Apr 2020 at 08:42, Edgar E. Iglesias
wrote:
>
> On Mon, Apr 20, 2020 at 10:22:05PM +0100, Peter Maydell wrote:
> > +if (env->thumb) {
> > +info._sifields._sigfault._addr -= 2;
> > +}
20.04.2020 16:32, Kevin Wolf wrote:
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previous preallocation, but just adds the zero flag to all
relevant L2 entries. If an external data file is in
On Tue, Apr 21, 2020 at 12:00 PM Jason Wang wrote:
>
> On 2020/4/20 下午5:32, Cindy Lu wrote:
> > From: Jason Wang
> >
> > Vhost-vdpa introduces VHOST_VDPA_SET_VRING_ENABLE which complies the
> > semantic of queue_enable defined in virtio spec. This method can be
> > used for preventing device
On 20/04/2020 17:55, Kevin Wolf wrote:
> Am 20.04.2020 um 12:41 hat Laurent Vivier geschrieben:
>> This series introduces new QMP/HMP commands to dump the status
>> of a a virtio device at different levels.
>
> What is the intended use case for these commands?
>
> If it's just for debugging,
20.04.2020 16:32, Kevin Wolf wrote:
Now that node level interface bdrv_truncate() supports passing request
flags to the block driver, expose this on the BlockBackend level, too.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
On Mon, 20 Apr 2020 18:35:58 -0400
Jared Rossi wrote:
> On 2020-04-20 08:29, Cornelia Huck wrote:
> > On Mon, 20 Apr 2020 14:26:17 +0200
> > Cornelia Huck wrote:
> >
> >> On Fri, 17 Apr 2020 14:38:38 -0400
> >> Jared Rossi wrote:
> >>
> >> > Remove the explicit prefetch check when using
20.04.2020 16:32, Kevin Wolf wrote:
Now that block drivers can support flags for .bdrv_co_truncate, expose
the parameter in the node level interfaces bdrv_co_truncate() and
bdrv_truncate().
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
[..]
@@ -4169,7 +4170,7
20.04.2020 16:32, Kevin Wolf wrote:
This adds a new BdrvRequestFlags parameter to the .bdrv_co_truncate()
driver callbacks, and a supported_truncate_flags field in
BlockDriverState that allows drivers to advertise support for request
flags in the context of truncate.
For now, we always pass 0
zstd significantly reduces cluster compression time.
It provides better compression performance maintaining
the same level of the compression ratio in comparison with
zlib, which, at the moment, is the only compression
method available.
The performance test results:
Test compresses and
Ping!
On 13.04.2020 14:12, Denis Plotnikov wrote:
Problem description: qcow2 internal snapshot saving time is too big on HDD ~ 25
sec
When a qcow2 image is placed on a regular HDD and the image is openned with
O_DIRECT the snapshot saving time is around 26 sec.
The snapshot saving time can be
The patch adds some preparation parts for incompatible compression type
feature to qcow2 allowing the use different compression methods for
image clusters (de)compressing.
It is implied that the compression type is set on the image creation and
can be changed only later by image conversion, thus
The test checks fulfilling qcow2 requirements for the compression
type feature and zstd compression type operability.
Signed-off-by: Denis Plotnikov
---
tests/qemu-iotests/287 | 146 +
tests/qemu-iotests/287.out | 67 +
v20:
04: fix a number of flaws [Vladimir]
* don't use $RAND_FILE passing to qemu-io,
so check $TEST_DIR is redundant
* re-arrage $RAND_FILE writing
* fix a typo
v19:
04: fix a number of flaws [Eric]
* remove rudundant test case descriptions
* fix
The patch enables processing the image compression type defined
for the image and chooses an appropriate method for image clusters
(de)compression.
Signed-off-by: Denis Plotnikov
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
---
block/qcow2-threads.c | 71
On Tue, Apr 21, 2020 at 11:23 AM Jason Wang wrote:
>
> On 2020/4/20 下午5:32, Cindy Lu wrote:
> > This is a small function that can get the peer from given
> NetClientState and queue_index
>
>
> Unnecessary space between 'function' and 'that'.
>
>
> >
> > Signed-off-by: Cindy Lu
>
>
> Please
On Mon, Apr 20, 2020 at 02:34:55PM +0100, Alex Bennée wrote:
> With --enable-plugins the gdb tests confuse things somewhat as the
> plugin code attempts to enumerate tests with non-existent binaries.
> Fortunately we already have a mechanism for these extra tests that
> don't automatically include
On Mon, Apr 20, 2020 at 10:22:06PM +0100, Peter Maydell wrote:
> Our code to identify syscall numbers has some issues:
> * for Thumb mode, we never need the immediate value from the insn,
>but we always read it anyway
> * bad immediate values in the svc insn should cause a SIGILL, but we
>
On 4/21/20 9:44 AM, Edgar E. Iglesias wrote:
> On Mon, Apr 20, 2020 at 10:22:05PM +0100, Peter Maydell wrote:
>> The kernel has different handling for syscalls with invalid
>> numbers that are in the "arm-specific" range 0x9f and up:
>> * 0x9f..0x9f07ff return -ENOSYS if not implemented
On Mon, Apr 20, 2020 at 10:22:04PM +0100, Peter Maydell wrote:
> We incorrectly treat SVC 0xf0002 as a cacheflush request (which is a
> NOP for QEMU). This is the wrong syscall number, because in the
> svc-immediate OABI syscall numbers are all offset by the
> ARM_SYSCALL_BASE value and so the
On Mon, Apr 20, 2020 at 10:22:03PM +0100, Peter Maydell wrote:
> In linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly
> to EXCP_SWI, which means that if the guest executes a BKPT insn then
> QEMU will perform a syscall for it (which syscall depends on what
> value happens to be in
On 4/20/20 11:22 PM, Peter Maydell wrote:
> In linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly
> to EXCP_SWI, which means that if the guest executes a BKPT insn then
> QEMU will perform a syscall for it (which syscall depends on what
> value happens to be in r7...). The correct
On 4/20/20 11:22 PM, Peter Maydell wrote:
> We incorrectly treat SVC 0xf0002 as a cacheflush request (which is a
> NOP for QEMU). This is the wrong syscall number, because in the
> svc-immediate OABI syscall numbers are all offset by the
> ARM_SYSCALL_BASE value and so the correct insn is SVC
On Mon, Apr 20, 2020 at 10:22:05PM +0100, Peter Maydell wrote:
> The kernel has different handling for syscalls with invalid
> numbers that are in the "arm-specific" range 0x9f and up:
> * 0x9f..0x9f07ff return -ENOSYS if not implemented
> * other out of range syscalls cause a SIGILL
>
Just use classes introduced in previous three commits. Behavior
difference is described in these three commits.
Drop group file, as it becomes unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/check | 965 ++-
21.04.2020 10:36, Vladimir Sementsov-Ogievskiy wrote:
Just use classes introduced in previous three commits. Behavior
difference is described in these three commits.
Drop group file, as it becomes unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/check | 965
All other test files are executable, except for this one. Fix that.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/283 | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 tests/qemu-iotests/283
diff --git a/tests/qemu-iotests/283
We are going to drop group file. Define group in tests as a preparatory
step.
The patch is generated by
cd tests/qemu-iotests
grep '^[0-9]\{3\} ' group | while read line; do
file=$(awk '{print $1}' <<< "$line");
groups=$(sed -e 's/^... //' <<< "$line");
awk
Add python script with new logic of searching for tests:
Current ./check behavior:
- tests are named [0-9][0-9][0-9]
- tests must be registered in group file (even if test doesn't belong
to any group, like 142)
Behavior of new test:
- group file is dropped
- tests are searched by
Add TestEnv class, which will handle test environment in a new python
iotests running framework.
Difference with current ./check interface:
- -v (verbose) option dropped, as it is unused
- -xdiff option is dropped, until somebody complains that it is needed
- same for -n option
Signed-off-by:
Rename bitmaps migration tests to demonstrate new test naming
convention.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/{199 => migrate-bitmaps-postcopy-test} | 0
tests/qemu-iotests/{199.out => migrate-bitmaps-postcopy-test.out} | 0
tests/qemu-iotests/{169 =>
QEMU_VXHS_PROG is used only in common.rc. So, move it to common.rc,
simplifying a bit further conversion of check into python
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/check | 15 ---
tests/qemu-iotests/common.rc | 14 ++
2 files changed, 14
Hi all!
This is a continuation for "[PATCH v2 0/2] Rework iotests finding",
so main user-visible feature here is removing tests/qemu-iotests/group
file, define groups in tests and allow human-readable names for iotests.
While being here, rewrite check into python :) I tried to keep most of
its
On 4/20/20 11:22 PM, Peter Maydell wrote:
> The kernel has different handling for syscalls with invalid
> numbers that are in the "arm-specific" range 0x9f and up:
> * 0x9f..0x9f07ff return -ENOSYS if not implemented
> * other out of range syscalls cause a SIGILL
> (see the kernel's
Add TestRunner class, which will run tests in a new python iotests
running framework.
There are some differences with current ./check behavior, most
significant are:
- Consider all tests self-executable, just run them, don't run python
by hand.
- Elapsed time is cached in json file
- Elapsed
We are going to be stricter about comparing test result with .out
files. So, fix some whitespaces now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/175.out | 2 +-
tests/qemu-iotests/267.out | 48 +++---
2 files changed, 25 insertions(+),
Somehow, this doesn't work if you just call ./277. But check 277 works.
We are going to new iotests running framework, which will consider test
files as self-executable, so let's just change it now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/277 | 2 +-
1 file changed, 1
On 4/21/20 12:53 AM, Dennis Clarke wrote:
> On 4/20/20 6:56 PM, Peter Maydell wrote:
>> On Fri, 17 Apr 2020 at 10:08, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> This fixes:
>>>
>>> $ qemu-system-ppc64 \
>>> -machine pseries-4.1 -cpu power9 \
>>> -smp 4 -m 12G -accel tcg ...
>>> ...
>>>
Use 1 container holding 2 regions:
- I/O registers
- FIFOs
Remove all the static base addresses.
Name address space.
Signed-off-by: Philippe Mathieu-Daudé
---
Sometime a patch is cleaner/quicker than explanations.
Suggestion to be squashed on patch:
'dwc-hsotg (dwc2) USB host controller
On Apr 21 02:38, Keith Busch wrote:
> The series looks good to me.
>
> Reviewed-by: Keith Busch
Thanks for the review Keith!
Kevin, should I rebase this on block-next? I think it might have some
conflicts with the PMR patch that went in previously.
Philippe, then I can also change the *err to
On 4/21/20 3:45 AM, Paul Zimmerman wrote:
> Wire the dwc-hsotg (dwc2) emulation into Qemu
>
> Signed-off-by: Paul Zimmerman
> ---
> hw/arm/bcm2835_peripherals.c | 21 -
> hw/usb/Kconfig | 5 +
> hw/usb/Makefile.objs | 1 +
>
201 - 298 of 298 matches
Mail list logo
