On 28.09.19 03:28, Peter Xu wrote:
> On Fri, Sep 27, 2019 at 03:33:20PM +0200, Igor Mammedov wrote:
>> On Thu, 26 Sep 2019 07:52:35 +0800
>> Peter Xu wrote:
>>
>>> On Wed, Sep 25, 2019 at 01:51:05PM +0200, Igor Mammedov wrote:
On Wed, 25 Sep 2019 11:27:00 +0800
Peter Xu wrote:
>
On Mon, 30 Sep 2019 12:41:39 +1000
David Gibson wrote:
> On Fri, Sep 27, 2019 at 04:27:12PM +0200, Greg Kurz wrote:
> > On Fri, 27 Sep 2019 15:50:19 +1000
> > David Gibson wrote:
> >
> > > This method depends only on the active irq controller. Now that we've
> > > formalized the notion of acti
On Mon, Sep 30, 2019 at 07:28:45AM +0200, Cédric Le Goater wrote:
> On 30/09/2019 03:49, David Gibson wrote:
> > On Fri, Sep 27, 2019 at 12:16:49PM +0200, Greg Kurz wrote:
> >> On Fri, 27 Sep 2019 15:50:16 +1000
> >> David Gibson wrote:
> >>
> >>> This method essentially represents code which belo
Hi,
Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
make it more lightweight, but also removed the ability to get the
architecture specific status of each vCPU.
This information was really useful to diagnose cert
On 28.09.19 21:03, Thomas Huth wrote:
> On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
> with regards to TCG, we also only support 64-bit host CPUs (see the
> check at the beginning of tcg/s390/tcg-target.inc.c), so we should
> remove s390 (without "x", i.e. the old 31-bit mod
Hi,
Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
make it more lightweight, but also removed the ability to get the
architecture specific status of each vCPU.
This information was really useful to diagnose cert
On 27.09.19 18:16, Richard Henderson wrote:
> On 9/27/19 4:02 AM, David Hildenbrand wrote:
>> On 26.09.19 18:26, Richard Henderson wrote:
>>> We currently set ilen to AUTO, then overwrite that during
>>> unwinding, then overwrite that for the code access case.
>>>
>>> This can be simplified to sett
On 27.09.19 18:02, Richard Henderson wrote:
> On 9/27/19 3:30 AM, David Hildenbrand wrote:
>>> +/* Update ILEN, except for breakpoint, where we didn't load an insn.
>>> */
>>> +if (ilen) {
>>> +env->int_pgm_ilen = ilen;
>>> +}
>>
>> I am not completely sure about breakpoint ha
On 30/09/2019 09.51, David Hildenbrand wrote:
> On 28.09.19 21:03, Thomas Huth wrote:
>> On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
>> with regards to TCG, we also only support 64-bit host CPUs (see the
>> check at the beginning of tcg/s390/tcg-target.inc.c), so we should
Same issue with the qemu version 4.1.0
Host: Windows 10
Guest: Archlinux 5.0.10
showkey output :
keycode 100 # Alt Gr
keycode 29# Left Control
keycode 97# Right Contol
keycode 56# Left Alt
no output # '> < \' key, should be 86
If I change the keyboard layout on the Host (Window
On Mon, Sep 30, 2019 at 08:11:56AM +0200, Cédric Le Goater wrote:
> On 27/09/2019 07:50, David Gibson wrote:
> > It turns out that all the logic in the SpaprIrq::reset hooks (and some in
> > the SpaprIrq::post_load hooks) isn't really related to resetting the irq
> > backend (that's handled by the
With qemu version 2.9.94
Host: Windows 10
Guest: Archlinux 5.0.10
showkey output :
keycode 56 press # Alt Gr
keycode 29 release # Alt Gr
keycode 56 release # Alt Gr
keycode 29 press # Left Control
keycode 29 release # Left Control
keycode 29 press # Right Contol
keycode 29 release # Righ
On Mon, Sep 30, 2019 at 09:22:16AM +0200, Greg Kurz wrote:
> On Mon, 30 Sep 2019 12:41:39 +1000
> David Gibson wrote:
>
> > On Fri, Sep 27, 2019 at 04:27:12PM +0200, Greg Kurz wrote:
> > > On Fri, 27 Sep 2019 15:50:19 +1000
> > > David Gibson wrote:
> > >
> > > > This method depends only on the
* Sergio Lopez (s...@redhat.com) wrote:
> Hi,
>
> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
> make it more lightweight, but also removed the ability to get the
> architecture specific status of each vCPU.
Signed-off-by: Andreas Schwab
---
linux-user/strace.list | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/strace.list b/linux-user/strace.list
index 63a946642d..863283418e 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -121,6 +121,9 @@
#ifdef TARGET_NR_dup2
On Fri, Sep 27, 2019 at 06:05:56PM +0200, Greg Kurz wrote:
> On Thu, 26 Sep 2019 10:56:46 +1000
> David Gibson wrote:
>
> > On Wed, Sep 25, 2019 at 10:55:35AM +0200, Cédric Le Goater wrote:
> > > On 25/09/2019 10:40, Greg Kurz wrote:
> > > > On Wed, 25 Sep 2019 16:45:20 +1000
> > > > David Gibson
Sergio Lopez writes:
> Hi,
>
> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
> make it more lightweight, but also removed the ability to get the
> architecture specific status of each vCPU.
>
> This informa
Thomas Huth writes:
> On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
> with regards to TCG, we also only support 64-bit host CPUs (see the
> check at the beginning of tcg/s390/tcg-target.inc.c), so we should
> remove s390 (without "x", i.e. the old 31-bit mode CPUs) from t
On Thu, Sep 26, 2019 at 10:11:05AM -0700, Richard Henderson wrote:
> On 9/26/19 12:50 AM, Peter Maydell wrote:
> > On Thu, 26 Sep 2019 at 00:31, Alex Bennée wrote:
> >>
> >> The 32 bit hosts are already a second class citizen especially with
> >> support for running 64 bit guests under TCG. We are
On Mon, 30 Sep 2019 09:09:59 +0200
Christian Borntraeger wrote:
> On 28.09.19 03:28, Peter Xu wrote:
> > On Fri, Sep 27, 2019 at 03:33:20PM +0200, Igor Mammedov wrote:
> >> On Thu, 26 Sep 2019 07:52:35 +0800
> >> Peter Xu wrote:
> >>
> >>> On Wed, Sep 25, 2019 at 01:51:05PM +0200, Igor Mamme
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Sep 17, 2019 at 05:00:55PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
>
> typo in subject
oops thanks.
>
> > Pull in the virtio_fs.h linux header and the constant for the virtiofs
> > ID.
> >
> > S
On Fri, 27 Sep 2019 at 14:40, Daniel P. Berrangé wrote:
>
> The following changes since commit d4e536f336d3d26c9fafa2a2549aaa0b014f5b6b:
>
> Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-09-24-v2'
> into staging (2019-09-26 10:13:39 +0100)
>
> are available in the Git repositor
On 30.09.19 11:33, Igor Mammedov wrote:
> On Mon, 30 Sep 2019 09:09:59 +0200
> Christian Borntraeger wrote:
>
>> On 28.09.19 03:28, Peter Xu wrote:
>>> On Fri, Sep 27, 2019 at 03:33:20PM +0200, Igor Mammedov wrote:
On Thu, 26 Sep 2019 07:52:35 +0800
Peter Xu wrote:
> On
On 30/09/2019 08:14, David Gibson wrote:
> On Mon, Sep 30, 2019 at 07:28:45AM +0200, Cédric Le Goater wrote:
>> On 30/09/2019 03:49, David Gibson wrote:
>>> On Fri, Sep 27, 2019 at 12:16:49PM +0200, Greg Kurz wrote:
On Fri, 27 Sep 2019 15:50:16 +1000
David Gibson wrote:
> This m
Alex Bennée writes:
> Sergio Lopez writes:
>
>> Hi,
>>
>> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
>> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
>> make it more lightweight, but also removed the ability to get the
>> architecture specific status
On 28.09.19 21:03, Thomas Huth wrote:
> On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
> with regards to TCG, we also only support 64-bit host CPUs (see the
> check at the beginning of tcg/s390/tcg-target.inc.c), so we should
> remove s390 (without "x", i.e. the old 31-bit
Heyall,
We have a use case where a host should self-fence (and all VMs should
die) if it doesn't hear back from a heartbeat within a certain time
period. Lots of ideas were floated around where libvirt could take
care of killing VMs or a separate service could do it. The concern
with those is that
On 24.09.19 16:47, Igor Mammedov wrote:
> From: Paolo Bonzini
>
> We may need to clear the dirty bitmap for more than one KVM memslot.
> First do some code movement with no semantic change.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Igor Mammedov
> Reviewed-by: Peter Xu
> ---
> acc
28.09.2019 2:36, John Snow wrote:
>
>
> On 9/27/19 8:23 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> Bitmaps reopening is buggy, reopening-rw just not working at all and
>> reopening-ro may lead to producing broken incremental
>> backup if we do temporary snapshot in a meantime.
>>
>>
On 30/09/19 12:04, Christian Borntraeger wrote:
> Paolo, ok it I pick the first 3 patches as well? Can you ack?
Yes, please.
Acked-by: Paolo Bonzini
Paolo
On Mon, 30 Sep 2019 at 11:26, Alex Bennée wrote:
> So if lots of people still want 32 bit host support for TCG guests we
> can probably come up with something that keeps existing functionality
> ticking over while leaving the newer architectural features to 64 bit
> hosts only.
I don't think we s
On Fri, 27 Sep 2019 at 15:42, Peter Maydell wrote:
>
> target-arm queue: nothing major here, but no point
> sitting on them waiting for more stuff to come along.
>
> thanks
> -- PMM
>
> The following changes since commit 1329132d28bf14b9508f7a1f04a2c63422bc3f99:
>
> Merge remote-tracking branch
On Sat, 28 Sep 2019 at 19:45, Markus Armbruster wrote:
>
> The following changes since commit c6f5012ba5fa834cbd5274b1b8369e2c5d2f5933:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-testing-next-260919-1' into staging (2019-09-27
> 15:43:41 +0100)
>
> are available in the Git r
From: "Dr. David Alan Gilbert"
Hi,
This set of patches adds the core of the virtio-fs support to qemu.
It's no longer marked experimental since both the spec and kernel have
been merged upstream.
A future set of patches will add the optional DAX mapping support.
The actual qemu change is
From: "Dr. David Alan Gilbert"
The virtio-fs virtio device provides shared file system access using
the FUSE protocol carried over virtio.
The actual file server is implemented in an external vhost-user-fs device
backend process.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Sebastien Boeuf
Si
From: "Dr. David Alan Gilbert"
Add the PCI version of vhost-user-fs.
Launch QEMU like this:
qemu -chardev socket,path=/tmp/vhost-fs.sock,id=chr0
-device vhost-user-fs-pci,tag=myfs,chardev=chr0
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Sebastien Boeuf
Signed-off-by: Dr. David Ala
From: "Dr. David Alan Gilbert"
Pull in the virtio_fs.h linux header and the constant for the virtiofs
ID; by running scripts/update-linux-headers.sh against
Linus's tree 97f9a3c4eee55b0178b518ae7114a6a53372913d.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Vivek Goyal
Signed-off-by: Dr. David
On 24.09.19 16:47, Igor Mammedov wrote:
> Changelog:
> since v6:
> - include and rebase on top of
>[PATCH 0/2] kvm: clear dirty bitmaps from all overlapping memslots
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg646200.html
> - minor fixups suggested during v6 re
Hi
On Mon, Sep 30, 2019 at 2:52 PM Dr. David Alan Gilbert (git)
wrote:
>
> From: "Dr. David Alan Gilbert"
>
> The virtio-fs virtio device provides shared file system access using
> the FUSE protocol carried over virtio.
> The actual file server is implemented in an external vhost-user-fs device
This looks like a libvirt bug at a first glance. Have you tried to
report it to the libvirt project? (See https://libvirt.org/bugs.html )
... also, can you re-create the bug with the very latest upstream
version of libvirt and qemu, or does it only occur with an (older?)
version of Ubuntu?
** Chan
On Fri, 20 Sep 2019 15:43:43 +0800
Tao Xu wrote:
> In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT),
> The initiator represents processor which access to memory. And in 5.2.27.3
> Memory Proximity Domain Attributes Structure, the attached initiator is
> defined as where the
On Mon, 30 Sep 2019 at 11:26, Alex Bennée wrote:
> The int128 support is due to the fact we are going to start to see newer
> architectures with things like 128 bit shadow capability registers and
> they will be a pain to shuffle around in 32 bit generated host code as
> well as requiring writing
Hi Igor,
On 09/24/19 13:19, Igor Mammedov wrote:
> On Mon, 23 Sep 2019 20:35:02 +0200
> "Laszlo Ersek" wrote:
>> I've got good results. For this (1/2) QEMU patch:
>>
>> Tested-by: Laszlo Ersek
>>
>> I tested the following scenarios. In every case, I verified the OVMF
>> log, and also the "info
Everybody who used something like "-machine accel=kvm:tcg" in the past
might be tempted to specify a similar list with the -accel parameter,
too, for example "-accel kvm:tcg". However, this is not how this
options is thought to be used, since each "-accel" should only take care
of one specific acce
On Mon, 30 Sep 2019 13:51:46 +0200
"Laszlo Ersek" wrote:
> Hi Igor,
>
> On 09/24/19 13:19, Igor Mammedov wrote:
> > On Mon, 23 Sep 2019 20:35:02 +0200
> > "Laszlo Ersek" wrote:
>
> >> I've got good results. For this (1/2) QEMU patch:
> >>
> >> Tested-by: Laszlo Ersek
> >>
> >> I tested the
On 29.09.19 18:31, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> This test can run just fine with other values for refcount_bits, so we
>> should filter the value from qcow2.py's dump-header.
>>
>> (036 currently ignores user-specified image options, but that will b
this is needed for remote gdb connections.
Signed-off-by: Bastian Koppelmann
---
target/tricore/translate.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/target/tricore/translate.c b/target/tricore/translate.c
index 832ff6328d..6c6303795d 100644
--- a/tar
EXCP_DEBUG is the only user. If we encounter a jump in tricore-gdb it's
target was overwritten by generate_qemu_excp() and we would never leave.
Signed-off-by: Bastian Koppelmann
---
target/tricore/translate.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/tricore/translate.c b/target
Hi,
this series fixes a few TriCore problems:
- Segfault due to non initialized ctx->env ptr (see
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03527.html)
I fixed this by properly detangling any reference of the env pointer in the
translate functions. (as suggested by Peter Mayd
this allows us to remove the references to env from ctx. This also fixes
a segfault that was due to the unititalized ctx->env ptr.
Reported-by: Andreas Konopik
Signed-off-by: Bastian Koppelmann
---
target/tricore/translate.c | 60 +-
1 file changed, 33 insert
Signed-off-by: Bastian Koppelmann
---
target/tricore/Makefile.objs | 2 +-
target/tricore/cpu.c | 10 +++
target/tricore/cpu.h | 2 +
target/tricore/gdbstub.c | 138 +++
4 files changed, 151 insertions(+), 1 deletion(-)
create mode 100644
this also removes tricore_cpu_get_phys_page_attrs_debug() as it was a
temporary fix from b190f477e29c7cd03a8fee49c96d27f160e3f5b0.
Signed-off-by: Bastian Koppelmann
---
target/tricore/cpu.c| 10 +-
target/tricore/helper.c | 13 +
2 files changed, 14 insertions(+), 9 delet
On Thu, 22 Aug 2019 at 11:50, Stefan Hajnoczi wrote:
> Thanks for writing up this summary! The requirements and possible
> solutions are now clear.
>
> We need someone willing to set up and maintain the CI.
>
> One-off tasks:
>
> 1. Create CI runners that offer similar cross-architecture coverage
On 29.09.19 18:31, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> Some tests require compat=1.1 and thus set IMGOPTS='compat=1.1'
>> globally. That is not how it should be done; instead, they should
>> simply set _unsupported_imgopts to compat=0.10 (compat=1.1 is th
On 29.09.19 18:33, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> Tests should not overwrite all user-supplied image options, but only add
>> to it (which will effectively overwrite conflicting values). Accomplish
>> this by passing options to _make_test_img via -o
On 29.09.19 18:33, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> Overwriting IMGOPTS means ignoring all user-supplied options, which is
>> not what we want. Replace the current IMGOPTS use by a new BACKING_FILE
>> variable.
>>
>> Signed-off-by: Max Reitz
>> ---
>>
On Fri, Sep 20, 2019 at 16:26:43 +0200, Peter Krempa wrote:
> Add 'features' field in the schema for commands and add a feature flag
> to advertise that the fix for savevm [1] is present.
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03487.html
>
> v2:
> - fixed typos pointed
On 29.09.19 18:34, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> The image end offset as reported by qemu-img check is different when
>> using an external data file; we do not care about its value here, so we
>> can just filter it.
>>
>> Signed-off-by: Max Reitz
>>
I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
/usr/share/ovmf/OVMF.fd
Using Ubuntu 18.04 LTS, default gnome desktop. There is no guest OS, there
is no hard drive, just the OVMF firmware locks it up. (I narrowed it
I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
/usr/share/ovmf/OVMF.fd
Using Ubuntu 18.04 LTS, default gnome desktop. There is no guest OS,
there is no hard drive, just the OVMF firmware locks it up. (I
narrowed it
On Tue, 24 Sep 2019 at 16:23, Heyi Guo wrote:
>
> As promised, this is the first RFC patch set for arm64 SDEI support.
Hi; for the benefit of possible reviewers who aren't familiar
with every corner of the arm ecosystem, could you provide a
summary of:
* what is SDEI ?
* what do KVM and QEMU wa
From: Thomas Huth
On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
with regards to TCG, we also only support 64-bit host CPUs (see the
check at the beginning of tcg/s390/tcg-target.inc.c), so we should
remove s390 (without "x", i.e. the old 31-bit mode CPUs) from the
list of s
From: Janosch Frank
Requests over 4k are not a spec exception.
Signed-off-by: Janosch Frank
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-4-git-send-email-imbre...@linux.ibm.com>
Acked-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/sclp.c | 3 +--
1 file
From: Igor Mammedov
s390 was trying to solve limited KVM memslot size issue by abusing
memory_region_allocate_system_memory(), which breaks API contract
where the function might be called only once.
Beside an invalid use of API, the approach also introduced migration
issue, since RAM chunks for
On Tue, 24 Sep 2019 at 16:23, Heyi Guo wrote:
>
> Override qemu_irq handler to support trigger SDEI event transparently
> after guest binds interrupt to SDEI event. We don't have good way to
> get GIC device and to guarantee SDEI device is initialized after GIC,
> so we search GIC in system bus wh
Instead of splitting at an unaligned address, we can simply split at
4TB.
Signed-off-by: Christian Borntraeger
Acked-by: Igor Mammedov
---
target/s390x/kvm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 54864c259c5e..
From: Igor Mammedov
Max memslot size supported by kvm on s390 is 8Tb,
move logic of splitting RAM in chunks upto 8T to KVM code.
This way it will hide KVM specific restrictions in KVM code
and won't affect board level design decisions. Which would allow
us to avoid misusing memory_region_allocat
From: Matthew Rosato
As discussed previously with Collin, I will take over maintaining
s390 pci.
Signed-off-by: Matthew Rosato
Message-Id: <1569590461-12562-1-git-send-email-mjros...@linux.ibm.com>
Acked-by: Collin Walling
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 2 +-
1 file c
From: Paolo Bonzini
Currently MemoryRegionSection has 1:1 mapping to KVMSlot.
However next patch will allow splitting MemoryRegionSection into
several KVMSlot-s, make sure that kvm_physical_log_slot_clear()
is able to handle such 1:N mapping.
Signed-off-by: Paolo Bonzini
Signed-off-by: Igor Mam
From: Janosch Frank
All sclp codes need to be checked for page boundary violations.
Signed-off-by: Janosch Frank
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-3-git-send-email-imbre...@linux.ibm.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390
u.git tags/s390x-20190930
for you to fetch changes up to c5b9ce518c0551d0198bcddadc82e03de9ac8de9:
s390/kvm: split kvm mem slots at 4TB (2019-09-30 13:51:50 +0200)
- do not abuse memory_region_allocate_system_memory and split
From: Claudio Imbrenda
Return the correct error code when the SCCB buffer is too small to
contain all of the output, for the Read SCP Information and
Read CPU Information commands.
Signed-off-by: Claudio Imbrenda
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-5-git-send-email-imbre.
From: Paolo Bonzini
We may need to clear the dirty bitmap for more than one KVM memslot.
First do some code movement with no semantic change.
Signed-off-by: Paolo Bonzini
Signed-off-by: Igor Mammedov
Reviewed-by: Peter Xu
Message-Id: <20190924144751.24149-2-imamm...@redhat.com>
Acked-by: Paol
From: Janosch Frank
Invalid command checking has to be done before the boundary check,
refactoring it now allows to insert the boundary check at the correct
place later.
Signed-off-by: Janosch Frank
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-2-git-send-email-imbre...@linux.ibm.c
From: Matthew Rosato
The fix in dbe9cf606c shrinks the IOMMU memory region to a size
that seems reasonable on the surface, however is actually too
small as it is based against a 0-mapped address space. This
causes breakage with small guests as they can overrun the IOMMU window.
Let's go back to
On 9/30/19 10:45 AM, Dr. David Alan Gilbert wrote:
> * Sergio Lopez (s...@redhat.com) wrote:
>> Hi,
>>
>> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
>> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
>> make it more lightweight, but also removed the abili
Patchew URL: https://patchew.org/QEMU/20190930123505.11607-1-th...@redhat.com/
Hi,
This series failed the 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.
=== TEST SCRIPT BEGIN ===
#!
On 29.09.19 18:38, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> When using an external data file, there are no refcounts for data
>> clusters. We thus have to adjust the corruption test in this patch to
>> not be based around a data cluster allocation, but the L2
On Mon, 2019-09-30 at 15:34 +0200, Max Reitz wrote:
> On 29.09.19 18:34, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > The only difference is that the json:{} filename of the image looks
> > > different. We actually do not care about that filename in this test
On 29.09.19 18:34, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> The only difference is that the json:{} filename of the image looks
>> different. We actually do not care about that filename in this test, we
>> are only interested in (1) that there is a json:{} fil
On Mon, 2019-09-30 at 14:43 +0200, Max Reitz wrote:
> On 29.09.19 18:31, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > This test can run just fine with other values for refcount_bits, so we
> > > should filter the value from qcow2.py's dump-header.
> > >
> > >
On 29.09.19 18:39, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
>> The problem with allowing the data_file option is that you want to use a
>> different data file per image used in the test. Therefore, we need to
>> allow patterns like -o data_file='$TEST_IMG.data_fi
On 30.09.19 15:40, Maxim Levitsky wrote:
> On Mon, 2019-09-30 at 14:43 +0200, Max Reitz wrote:
>> On 29.09.19 18:31, Maxim Levitsky wrote:
>>> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
This test can run just fine with other values for refcount_bits, so we
should filter the value
On Mon, 2019-09-30 at 15:38 +0200, Max Reitz wrote:
> On 29.09.19 18:38, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > When using an external data file, there are no refcounts for data
> > > clusters. We thus have to adjust the corruption test in this patch to
On 30.09.19 15:46, Maxim Levitsky wrote:
> On Mon, 2019-09-30 at 15:38 +0200, Max Reitz wrote:
>> On 29.09.19 18:38, Maxim Levitsky wrote:
>>> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
When using an external data file, there are no refcounts for data
clusters. We thus have to a
On Mon, 2019-09-30 at 15:44 +0200, Max Reitz wrote:
> On 30.09.19 15:40, Maxim Levitsky wrote:
> > On Mon, 2019-09-30 at 14:43 +0200, Max Reitz wrote:
> > > On 29.09.19 18:31, Maxim Levitsky wrote:
> > > > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > > > This test can run just fine wit
On 30.09.19 15:58, Maxim Levitsky wrote:
> On Mon, 2019-09-30 at 15:44 +0200, Max Reitz wrote:
>> On 30.09.19 15:40, Maxim Levitsky wrote:
>>> On Mon, 2019-09-30 at 14:43 +0200, Max Reitz wrote:
On 29.09.19 18:31, Maxim Levitsky wrote:
> On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
On Mon, 2019-09-30 at 15:57 +0200, Max Reitz wrote:
> On 30.09.19 15:46, Maxim Levitsky wrote:
> > On Mon, 2019-09-30 at 15:38 +0200, Max Reitz wrote:
> > > On 29.09.19 18:38, Maxim Levitsky wrote:
> > > > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > > > When using an external data fil
CCing qemu-devel and QEMU developers.
On Mon, Sep 30, 2019 at 12:24:53PM +0200, Jiri Denemark wrote:
> On Thu, Sep 26, 2019 at 18:43:05 -0300, Eduardo Habkost wrote:
> > The pconfig feature never worked, and adding "pconfig=off" to the
> > QEMU command-line triggers a regression in QEMU 3.1.1 and
On Mon, 2019-09-30 at 16:04 +0200, Max Reitz wrote:
> On 30.09.19 15:58, Maxim Levitsky wrote:
> > On Mon, 2019-09-30 at 15:44 +0200, Max Reitz wrote:
> > > On 30.09.19 15:40, Maxim Levitsky wrote:
> > > > On Mon, 2019-09-30 at 14:43 +0200, Max Reitz wrote:
> > > > > On 29.09.19 18:31, Maxim Levits
below
> -Original Message-
> From: de...@edk2.groups.io On Behalf Of Igor
> Mammedov
> Sent: Monday, September 30, 2019 8:37 PM
> To: Laszlo Ersek
> Cc: de...@edk2.groups.io; qemu-devel@nongnu.org; Chen, Yingwen
> ; phillip.go...@oracle.com;
> alex.william...@redhat.com; Yao, Jiewen ; Na
* Felipe Franciosi (fel...@nutanix.com) wrote:
> Heyall,
>
> We have a use case where a host should self-fence (and all VMs should
> die) if it doesn't hear back from a heartbeat within a certain time
> period. Lots of ideas were floated around where libvirt could take
> care of killing VMs or a s
On Mon, 2019-09-30 at 15:00 +0200, Max Reitz wrote:
> On 29.09.19 18:33, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > Tests should not overwrite all user-supplied image options, but only add
> > > to it (which will effectively overwrite conflicting values). A
On Mon, 2019-09-30 at 15:01 +0200, Max Reitz wrote:
> On 29.09.19 18:33, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > Overwriting IMGOPTS means ignoring all user-supplied options, which is
> > > not what we want. Replace the current IMGOPTS use by a new BACKI
> -Original Message-
> From: Eduardo Habkost
> Sent: Monday, September 30, 2019 22:11
> To: Jiri Denemark
> Cc: libvir-l...@redhat.com; qemu-devel@nongnu.org; Paolo Bonzini
> ; Daniel P. Berrangé ; Kang,
> Luwei ; thomas.lenda...@amd.com; Robert Hoo
> ; Richard Henderson ; Jiri
> Denemark
On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> Also, check on the hardware the behavior listed as 'undefined' for vsl/vsr
> in the docs - even though it is tehnically irrelevant, I am courious
> whether the old or the new (or none of them) solution match the hardware.
There does appear to be som
> 5. (a question for Mark) After all recent changes, does get_avr64(...,
..., true) always (for any endian configuration) return the "high" half of
an Altivec register, and get_avr64(..., ..., false) the "low" one?
>
> Given all these circumstances, perhaps the most reasonable solution would
be to
Patchew URL:
https://patchew.org/QEMU/20190930124643.179695-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190930124643.179695-1-kbast...@mail.uni-paderborn.de
Subject: [PATCH 0/5] T
On Mon, 2019-09-30 at 14:59 +0200, Max Reitz wrote:
> On 29.09.19 18:31, Maxim Levitsky wrote:
> > On Fri, 2019-09-27 at 11:42 +0200, Max Reitz wrote:
> > > Some tests require compat=1.1 and thus set IMGOPTS='compat=1.1'
> > > globally. That is not how it should be done; instead, they should
> > >
30.09.2019. 16.35, "Paul Clarke" је написао/ла:
>
> On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> > Also, check on the hardware the behavior listed as 'undefined' for
vsl/vsr
> > in the docs - even though it is tehnically irrelevant, I am courious
> > whether the old or the new (or none of them
1 - 100 of 224 matches
Mail list logo
