On Thu, Sep 27, 2018 at 04:45:57PM +, Singh, Brijesh wrote:
[...]
> +static MemTxResult amdvi_mem_ir_write(void *opaque, hwaddr addr,
> + uint64_t value, unsigned size,
> + MemTxAttrs attrs)
> +{
> +int ret;
> +
On Thu, Sep 27, 2018 at 04:45:56PM +, Singh, Brijesh wrote:
> To be consistent with intel-iommu:
>
> - rename the address space to use '_' instead of '-'
> - update the memory region relationships
>
> Signed-off-by: Brijesh Singh
> Cc: Peter Xu
> Cc: "Michael S. Tsirkin"
> Cc: Paolo
On Thu, Sep 27, 2018 at 04:45:55PM +, Singh, Brijesh wrote:
> Currently, the amdvi_validate_dte() assumes that a valid DTE will
> always have V=1. This is not true. The V=1 means that bit[127:1] are
> valid. A valid DTE can have IV=1 and V=0 (i.e address translation
> disabled and interrupt
On Wed, Sep 05, 2018 at 02:23:07PM +0800, Peter Xu wrote:
> Based-on: <20180828191048.29806-1-arm...@redhat.com>
> Based-on: <2018090716.1675-1-arm...@redhat.com>
>
> (this series is based on Markus's monitor-next tree)
>
> v8:
> - remove patch 1 & 2 since already in the QAPI pull
> - squash
On Thu, Sep 13, 2018 at 03:55:17PM +0800, Peter Xu wrote:
> There are two callers for vtd_sync_shadow_page_table_range(), one
> provided a valid context entry and one not. Move that fetching
> operation into the caller vtd_sync_shadow_page_table() where we need to
> fetch the context entry.
>
>
On Fri, Sep 07, 2018 at 10:46:40AM +0800, Peter Xu wrote:
> QEMU is not handling the global DMAR switch well, especially when from
> "on" to "off".
>
> Let's first take the example of system reset.
>
> Assuming that a guest has IOMMU enabled. When it reboots, we will drop
> all the existing
On September 27, 2018 5:53:34 PM CEST, Eric Blake wrote:
>On 9/26/18 11:04 AM, Leonid Bloch wrote:
>> The default cache-clean-interval is set to 10 minutes, in order to
>lower
>> the overhead of the qcow2 caches (before the default was 0, i.e.
>> disabled).
>>
>> * For non-Linux platforms the
On 2018-09-21 at 15:13:32 +0400, Marc-André Lureau wrote:
Thanks for the improvemnet.
Reviewed-by: Zhang Yi
> Put into use the macros proposed in the previous Object documentation change.
>
> Signed-off-by: Marc-André Lureau
> ---
> include/hw/mem/nvdimm.h | 1 +
> hw/acpi/ich9.c |
On Thu, Sep 27, 2018 at 02:35:07PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Thu, Sep 27, 2018 at 10:46:34AM +0200, Markus Armbruster wrote:
> >> Peter Xu writes:
> >>
> >> > On Tue, Sep 25, 2018 at 01:09:57PM +0200, Wolfgang Bumiller wrote:
> >> >>
> >> >> > On September
On Thu, Sep 27, 2018 at 12:28:42PM +, Singh, Brijesh wrote:
> >> +static bool amdvi_validate_int_remap(AMDVIState *s, uint64_t *dte)
> >> +{
> >> +/* Check if IR is enabled in DTE */
> >> +if (!(dte[2] & AMDVI_IR_REMAP_ENABLE)) {
> >> +return false;
> >> +}
> >> +
> >> +
This test boots OVMF and check the debug console (I/O port on the ISA bus)
report enough information on the initialized devices.
Example:
$ avocado --show=QMP,serial run tests/acceptance/boot_firmware.py
Signed-off-by: Philippe Mathieu-Daudé
---
- how to refactor common code from
Hi,
This RFC series add simple acceptance tests which boot SeaBIOS and EDK2 on
Q35 and virt/aarch64.
It is more of a proof of concept (to motivate the Avocado team ;) ).
Regards,
Phil.
Philippe Mathieu-Daudé (3):
acceptance tests: Add SeaBIOS boot and debug console checking test
This test boots EDK2 AAVMF and check the debug console (PL011) reports enough
information on the initialized devices.
Example:
$ avocado --show=console run tests/acceptance/boot_firmware.py
--cit-parameter-file aarch64.cit
having aarch64.cit:
[parameters]
qemu_bin:
This test boots SeaBIOS and check the debug console (I/O port on the ISA bus)
reports enough information on the initialized devices.
Example:
$ avocado --show=debugcon run tests/acceptance/boot_firmware.py
Signed-off-by: Philippe Mathieu-Daudé
---
- can we avoid the time.time() 2nd timeout
On 09/27/2018 03:50 AM, David Hildenbrand wrote:
On 27/09/2018 00:54, Tony Krowiak wrote:
A new CPU model feature and two new CPU model facilities are
introduced to support AP devices for a KVM guest.
CPU model features:
1. The S390_FEAT_AP CPU model feature indicates whether AP
On 09/27/2018 03:41 AM, David Hildenbrand wrote:
On 27/09/2018 00:54, Tony Krowiak wrote:
Updates the linux header files in preparation for introduction
of the VFIO AP device:
* Added a feature ID to indicate AP facilities are installed
* Added device attributes to the KVM_S390_VM_CRYPTO
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 17 +++-
target/arm/translate-a64.h | 1 +
target/arm/translate.h | 1 +
linux-user/elfload.c | 6 +-
target/arm/cpu64.c | 13 ++---
target/arm/helper.c| 2 +-
The missing nibble made it more difficult to read.
Signed-off-by: Richard Henderson
---
target/arm/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 17c9c43f41..03bf28f533 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 6 +-
linux-user/elfload.c | 2 +-
target/arm/cpu.c | 4
target/arm/helper.c | 2 +-
target/arm/machine.c | 3 +--
5 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index
There are more feature bits that could be converted, but I thought
I should show the work to this point to get feedback.
This is the "v2" as compared to
http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg01849.html
r~
Richard Henderson (9):
target/arm: Define fields of ISAR
Both arm and thumb2 division are controlled by the same ISAR field,
which takes care of the arm implies thumb case. Having M imply
thumb2 division was wrong for cortex-m0, which is v6m and does not
have thumb2 at all, much less thumb2 division.
Signed-off-by: Richard Henderson
---
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 80
1 file changed, 80 insertions(+)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 65c0fa0a65..e1b9270b8c 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1428,6 +1428,86 @@
Having V6 alone imply jazelle was wrong for cortex-m0.
Change to an assertion for V6 & !M.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 6 +-
target/arm/translate.h | 1 +
target/arm/cpu.c | 17 ++---
target/arm/translate.c | 2 +-
4 files changed, 21
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 16 +++-
target/arm/translate-a64.h | 1 +
linux-user/aarch64/signal.c | 4 ++--
linux-user/elfload.c| 2 +-
linux-user/syscall.c| 10 ++
target/arm/cpu64.c | 3 ++-
The "tests/acpi-test-data" files are currently not covered by any section
in MAINTAINERS, and "scripts/checkpatch.pl" complains when new data files
are added.
Cc: "Michael S. Tsirkin"
Cc: Alex Williamson
Cc: Gerd Hoffmann
Cc: Igor Mammedov
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
Most of the v8 extensions are self-contained within the ISAR
registers and are not implied by other feature bits, which
makes them the easiest to convert.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 123 +
target/arm/translate-a64.h |
On 9/26/18 11:11 PM, Thomas Huth wrote:
> Older versions of Clang (before 3.5) and GCC (before 4.1) do not
> support the "__attribute__((flatten))" yet. We don't care about
> such old versions of GCC anymore, but since Clang 3.4 is still
> used in EPEL for RHEL7 / CentOS 7, we should not use this
In commit 9fa99d2519cb ("hw/pci-host: Fix x86 Host Bridges 64bit PCI
hole", 2017-11-16), we meant to expose such a 64-bit PCI MMIO aperture in
the ACPI DSDT that would be at least as large as the new "pci-hole64-size"
property (2GB on i440fx, 32GB on q35). The goal was to offer "enough"
64-bit
The incorrect value advertised only thumb2 div without arm div.
Signed-off-by: Richard Henderson
---
target/arm/cpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 03bf28f533..020e79918b 100644
--- a/target/arm/cpu.c
+++
This is v2 of the series previously posted at
<20180924221346.16733-1-lersek@redhat.com">http://mid.mail-archive.com/20180924221346.16733-1-lersek@redhat.com>.
Changes are noted on every patch.
The bios-tables-test case depends on Gerd's "[PATCH] pci-testdev: add
optional memory bar" at
In commit 9fa99d2519cb ("hw/pci-host: Fix x86 Host Bridges 64bit PCI
hole", 2017-11-16), we meant to expose such a 64-bit PCI MMIO aperture in
the ACPI DSDT that would be at least as large as the new "pci-hole64-size"
property (2GB on i440fx, 32GB on q35). The goal was to offer "enough"
64-bit
Expose the calculated "hole64 start" GPAs as plain uint64_t values,
extracting the internals of the current property getters.
This patch doesn't change behavior.
Cc: "Michael S. Tsirkin"
Cc: Alex Williamson
Cc: Gerd Hoffmann
Cc: Igor Mammedov
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
On 9/26/18 2:29 AM, Mao Zhongyi wrote:
Since this one is intended to be a user-facing error message
rather than just a debug note, it could also be reasonably
expanded to be a bit more user friendly.
Reported-by: Peter Maydell
Signed-off-by: Mao Zhongyi
---
hw/i386/multiboot.c | 3 ++-
1
On 9/27/18 7:16 PM, Eric Blake wrote:
> On 9/27/18 11:42 AM, Peter Maydell wrote:
>> Taking the address of a field in a packed struct is a bad idea, because
>> it might not be actually aligned enough for that pointer type (and
>> thus cause a crash on dereference on some host architectures). Newer
CCing Markus and Eric, so they can help review the error message
grammar and style.
On Wed, Sep 26, 2018 at 03:29:48AM -0400, Mao Zhongyi wrote:
> Since this one is intended to be a user-facing error message
> rather than just a debug note, it could also be reasonably
> expanded to be a bit
On 9/27/18 5:55 PM, Peter Maydell wrote:
> If QEMU is compiled with clang-7 it results in the warning:
>
> hw/display/qxl.c:1884:19: error: misaligned or large atomic operation
> may incur significant performance penalty [-Werror,-Watomic-alignment]
> old_pending =
On 27 September 2018 at 19:16, Eric Blake wrote:
> Okay, I am also in favor of the complete conversion. Want me to squash in
> the remaining 3 spots as part of queuing my patch, so you don't have to send
> a v2?
Yes, please.
thanks
-- PMM
On 09/27/18 14:10, Gerd Hoffmann wrote:
> Add memory bar to pci-testdev. Size is configurable using the membar
> property. Setting the size to zero (default) turns it off. Can be used
> to check whenever guests handle large pci bars correctly.
>
> Signed-off-by: Gerd Hoffmann
> ---
>
On Thu, Sep 27, 2018 at 5:29 PM Alex Bennée wrote:
>
>
> Peter Maydell writes:
>
> > On 27 September 2018 at 16:42, Alex Bennée wrote:
> >> If you can rebuild with:
> >>
> >> ./configure --enable-debug --extra-cflags="-O0 -g3
> >> -fno-omit-frame-pointer"
> >
> > -O0 is the default if you
On 09/27/18 09:03, Igor Mammedov wrote:
> On Thu, 27 Sep 2018 00:31:07 +0200
> Laszlo Ersek wrote:
>> - I guess I could ascertain the mis-alignment by using small guest RAM
>> (128MB), a single DIMM hotplug slot so that reserved-memory-end is
>> rounded up to 5GB (through the 1GB alignment), and
On 07.08.18 19:43, Vladimir Sementsov-Ogievskiy wrote:
> Start several async requests instead of read chunk by chunk.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.c | 208
> --
> 1 file changed, 204 insertions(+), 4
On 9/27/18 1:03 PM, Peter Maydell wrote:
I'm a bit confused. After applying your patch (and rebasing it to my pending
pull request), I still found instances of be16_to_cpus() and others. Were
you only flipping instances that were members of a packed struct, while
leaving other instances
On 27 September 2018 at 18:30, Eric Blake wrote:
> On 9/27/18 11:42 AM, Peter Maydell wrote:
>>
>> Taking the address of a field in a packed struct is a bad idea, because
>> it might not be actually aligned enough for that pointer type (and
>> thus cause a crash on dereference on some host
On 09/26/2018 10:23 PM, Eric Blake wrote:
> On 9/25/18 6:49 PM, John Snow wrote:
>> based on: jsnow/bitmaps staging branch
>>
>> This series builds on a previous standalone patch and adjusts
>> the permission for all (or most) of the QMP bitmap commands.
>>
>> John Snow (5):
>>
On 07.08.18 19:43, Vladimir Sementsov-Ogievskiy wrote:
> Memory allocation may become less efficient for encrypted case. It's a
> payment for further asynchronous scheme.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.c | 114
>
On 09/26/2018 10:17 PM, Eric Blake wrote:
> On 9/26/18 6:53 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 26.09.2018 02:49, John Snow wrote:
>>> Instead of both frozen and qmp_locked checks, wrap it into one check.
>>> frozen implies the bitmap is split in two (for backup), and shouldn't
>>> be
On 9/27/18 11:42 AM, Peter Maydell wrote:
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the
On 09/27/2018 10:09 AM, Eric Blake wrote:
> On 9/27/18 2:31 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 27.09.2018 00:28, John Snow wrote:
>>> We have been neglecting to do so, which results in wrong counts
>>> after merge. In the worst case, we may think the bitmap is empty
>>> when it has had
On 09/26/2018 11:11 PM, Eric Blake wrote:
> We need an accurate count of the number of bits set in a bitmap
> after a merge. In particular, since the merge operation short-circuits
> a merge from an empty source, if you have bitmaps A, B, and C where
> B started empty, then merge C into B, and
On 09/26/2018 10:25 PM, Eric Blake wrote:
> On 9/19/18 4:16 PM, John Snow wrote:
>>
>>
>> On 09/19/2018 05:08 PM, Eric Blake wrote:
>>> On 9/19/18 2:58 PM, John Snow wrote:
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their
On 9/27/18 11:42 AM, Peter Maydell wrote:
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the
On 27 September 2018 at 18:02, Peter Maydell wrote:
> clang 7 complains about taking the address of a member of a
> packed struct, which is good because those are usually bugs.
> Unfortunately it also means it complains a lot if you pass
> _struct->field to __get_user or __put_user, even
> though
This is an alternative fix to Marc's original patch as per Paolo's suggestion.
Reported-by: Marc-André Lureau
Suggested-by: Paolo Bonzini
Signed-off-by: Alex Bennée
---
cpus.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index 719788320f..d7d69a101e
Thank you for your reviews, Philippe,
> Fredrik: maybe you can simply name the C790 in the comment pointing to
> the DS documentation.
Sure, I will do that for v6! I am also adding some of Maciej's notes on the
differences between the C790 and the R5900, along with PRId 0X2E00 as noted
by
On 9/27/18 8:55 AM, Peter Maydell wrote:
> If QEMU is compiled with clang-7 it results in the warning:
>
> hw/display/qxl.c:1884:19: error: misaligned or large atomic operation
> may incur significant performance penalty [-Werror,-Watomic-alignment]
> old_pending =
On 07.08.18 19:43, Vladimir Sementsov-Ogievskiy wrote:
> We don't need locking for encryption code.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
On 27 September 2018 at 17:59, Richard Henderson wrote:
> On 9/27/18 5:53 AM, Peter Maydell wrote:
>> Maybe I can do something to persuade the compiler that the
>> pointer really is 4 aligned...
>
> Hopefully __builtin_assume_aligned(ptr, 4) is supported by that version of
> clang?
Yes; I sent
clang 7 complains about taking the address of a member of a
packed struct, which is good because those are usually bugs.
Unfortunately it also means it complains a lot if you pass
_struct->field to __get_user or __put_user, even
though in fact those macros are totally safe, since their
entire
On 27.09.18 18:58, Max Reitz wrote:
> On 07.08.18 19:43, Vladimir Sementsov-Ogievskiy wrote:
>> From: "Denis V. Lunev"
>>
>> We are not working with a shared state data in the decruption code and
(*decryption)
>> thus this operation is safe. On the other hand this significantly
>> reduces the
On 9/27/18 5:53 AM, Peter Maydell wrote:
> Maybe I can do something to persuade the compiler that the
> pointer really is 4 aligned...
Hopefully __builtin_assume_aligned(ptr, 4) is supported by that version of
clang?
r~
On 07.08.18 19:43, Vladimir Sementsov-Ogievskiy wrote:
> From: "Denis V. Lunev"
>
> We are not working with a shared state data in the decruption code and
> thus this operation is safe. On the other hand this significantly
> reduces the scope of the lock.
Sure, but does it have any effect?
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Now that amd-iommu support interrupt remapping, enable the GASup in IVRS
table and GASup in extended feature register to indicate that IOMMU
support guest virtual APIC mode. GASup provides option to guest OS to
make use of 128-bit IRTE.
Note that the GAMSup is set to zero to indicate that
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
To be consistent with intel-iommu:
- rename the address space to use '_' instead of '-'
- update the memory region relationships
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom
Interrupt remapping needs kernel-irqchip={off|split} on both Intel and AMD
platforms. Move the check in common place.
Signed-off-by: Brijesh Singh
Reviewed-by: Peter Xu
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
The vtd_generate_msi_message() in intel-iommu is used to construct a MSI
Message from IRQ. A similar function will be needed when we add interrupt
remapping support in amd-iommu. Moving the function in common file to
avoid the code duplication. Rename it to x86_iommu_irq_to_msi_message().
There is
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
---
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e address translation
disabled and interrupt remapping enabled)
Remove the V=1 check from amdvi_validate_dte(), make
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by not using the
"modify in place" byte
Peter Maydell writes:
> On 27 September 2018 at 16:42, Alex Bennée wrote:
>> If you can rebuild with:
>>
>> ./configure --enable-debug --extra-cflags="-O0 -g3 -fno-omit-frame-pointer"
>
> -O0 is the default if you specify --enable-debug, you don't
> need to specify it separately. -O0 also
On 09/27/18 17:24, Eric Blake wrote:
> On 9/26/18 3:35 PM, Laszlo Ersek wrote:
>> (+Eric)
>
>> This too sounds useful. AIUI, ftruncate() is neither forbidden, nor
>> required, to allocate filesystem extents when increasing the size of a
>> file. Using one smaller regular temporary file as the
On Thu, Sep 27, 2018 at 6:07 AM Pankaj Gupta wrote:
[..]
> > We are plugging VIRTIO based flush callback for virtio_pmem driver. If pmem
> > driver (pmem_make_request) has to queue request we have to plug "blk_mq_ops"
> > callbacks for corresponding VIRTIO vqs. AFAICU there is no existing
> >
If QEMU is compiled with clang-7 it results in the warning:
hw/display/qxl.c:1884:19: error: misaligned or large atomic operation
may incur significant performance penalty [-Werror,-Watomic-alignment]
old_pending = atomic_fetch_or(>ram->int_pending, le_events);
^
This is
On 9/26/18 11:04 AM, Leonid Bloch wrote:
The default cache-clean-interval is set to 10 minutes, in order to lower
the overhead of the qcow2 caches (before the default was 0, i.e.
disabled).
* For non-Linux platforms the default is kept at 0, because
cache-clean-interval is not supported
On 27 September 2018 at 16:42, Alex Bennée wrote:
> If you can rebuild with:
>
> ./configure --enable-debug --extra-cflags="-O0 -g3 -fno-omit-frame-pointer"
-O0 is the default if you specify --enable-debug, you don't
need to specify it separately. -O0 also implies -fno-omit-frame-pointer.
Filipe Manana writes:
> Hello,
>
> Recently qemu started hanging when running fstests (xfstests) after
> upgrading the guests kernel (linux) from 4.15.x to 4.16. Nothing else
> changed in the host or guest, besides the kernel version in the guest.
>
> Running fstests always hangs when running
On Thu, Sep 27, 2018 at 12:06 PM Tomáš Golembiovský
wrote:
> Hi Michael,
>
> thanks for looking into this. My comments are below.
>
> Adding Sameeh...
>
>
> On Wed, 26 Sep 2018 12:15:48 -0500
> Michael Roth wrote:
>
> > Quoting Tomáš Golembiovský (2018-09-07 06:42:09)
> > > The guest-get-fsinfo
During live migration, when stopping vhost-user device, 'vhost_dev_stop'
will be called, 'vhost_dev_stop' will call a batch of 'vhost_user_read'
and 'vhost_user_write'. If a previous 'vhost_user_read' or 'vhost_user_write'
failed because the vhost user backend failed, the 'CHR_EVENT_CLOSED' event
During live migration, when stopping vhost-user device, 'vhost_dev_stop'
will be called, 'vhost_dev_stop' will call a batch of 'vhost_user_read'
and 'vhost_user_write'. If a previous 'vhost_user_read' or 'vhost_user_write'
failed because the vhost user backend failed, the 'CHR_EVENT_CLOSED' event
On 9/26/18 3:35 PM, Laszlo Ersek wrote:
(+Eric)
This too sounds useful. AIUI, ftruncate() is neither forbidden, nor
required, to allocate filesystem extents when increasing the size of a
file. Using one smaller regular temporary file as the common foundation
for multiple "memory-backend-file"
Am 26.09.2018 um 18:04 hat Leonid Bloch geschrieben:
> This series makes the qcow2 L2 cache assignment aware of the image size,
> with the intention for it to cover the entire image. The importance of
> this change is in noticeable performance improvement, especially with
> heavy random I/O. The
On 9/26/18 3:26 PM, Laszlo Ersek wrote:
(+Eric)
I see shm_open() is used heavily in ivshmem-related tests. I haven't
looked much at shm_open() before. (I've always known it existed in
POSIX, but I've never cared.)
I've never actually played with shm_open() myself, but understand the
On 27.09.18 16:23, Alberto Garcia wrote:
> On Thu 27 Sep 2018 04:14:15 PM CEST, Max Reitz wrote:
>> On 25.09.18 16:13, Alberto Garcia wrote:
>>> On Thu 13 Sep 2018 08:37:05 PM CEST, Max Reitz wrote:
First, split .003 into the part we want to commit and the part we
don't want to commit.
On 9/27/18 4:21 AM, Laszlo Ersek wrote:
On 09/27/18 07:48, Gerd Hoffmann wrote:
Hi,
Maybe using memdev file backend with manually created sparse file
might actually work (with preallocate disabled)
Thanks, this sounds like a good idea.
I see shm_open() is used heavily in ivshmem-related
On Wed, Sep 26, 2018 at 05:24:27PM +0200, Igor Mammedov wrote:
> On Tue, 25 Sep 2018 18:02:48 +0200
> Kashyap Chamarthy wrote:
[...]
> > +(1) Launch QEMU as follows (note that the "maxcpus" is mandatory to
> > +allow vCPU hotplug)::
> > +
> > + $ qemu-system-x86_64 -display none
Igor Mammedov writes:
> On Tue, 25 Sep 2018 18:02:48 +0200
> Kashyap Chamarthy wrote:
>
>> Signed-off-by: Kashyap Chamarthy
>> ---
>> docs/cpu-hotplug.rst | 140 +++
>> 1 file changed, 140 insertions(+)
>> create mode 100644 docs/cpu-hotplug.rst
>>
>>
On Thu 27 Sep 2018 04:14:15 PM CEST, Max Reitz wrote:
> On 25.09.18 16:13, Alberto Garcia wrote:
>> On Thu 13 Sep 2018 08:37:05 PM CEST, Max Reitz wrote:
>>> First, split .003 into the part we want to commit and the part we
>>> don't want to commit. This is a bit tricky without qemu-img dd @seek
On 25.09.18 16:13, Alberto Garcia wrote:
> On Thu 13 Sep 2018 08:37:05 PM CEST, Max Reitz wrote:
>> First, split .003 into the part we want to commit and the part we
>> don't want to commit. This is a bit tricky without qemu-img dd @seek
>> (or a corresponding convert parameter), so we'll have to
Hi
On Thu, Sep 27, 2018 at 5:57 PM Alex Bennée wrote:
>
>
> Marc-André Lureau writes:
>
> > Spotted by ASAN:
> >
> > QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/bios-tables-test
> > -p /x86_64/acpi/piix4/cpuhp
> > /x86_64/acpi/piix4/cpuhp: Could not access KVM kernel module: No
On 2018-09-27 15:02, David Hildenbrand wrote:
> These flags allow us to later on detect if a DATA program interrupt
> is to be injected, and which DXC (1,2,3) is to be used.
>
> Interestingly, some support FP instructions are considered as HFP
> instructions (I assume simply because they were
On 9/27/18 2:31 AM, Vladimir Sementsov-Ogievskiy wrote:
27.09.2018 00:28, John Snow wrote:
We have been neglecting to do so, which results in wrong counts
after merge. In the worst case, we may think the bitmap is empty
when it has had new writes merged into it.
Reported-by: Eric Blake
On 2018-09-27 15:03, David Hildenbrand wrote:
> Let's check this also at a central place.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 138 ++---
> target/s390x/translate.c | 83
Marc-André Lureau writes:
> Spotted by ASAN:
>
> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/bios-tables-test
> -p /x86_64/acpi/piix4/cpuhp
> /x86_64/acpi/piix4/cpuhp: Could not access KVM kernel module: No such file or
> directory
> qemu-system-x86_64: failed to initialize
On 2018-09-27 00:54, Tony Krowiak wrote:
> Introduces a VFIO based AP device. The device is defined via
> the QEMU command line by specifying:
>
> -device vfio-ap,sysfsdev=
>
> There may be only one vfio-ap device configured for a guest.
>
> The mediated matrix device is created by the VFIO
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by not using the
"modify in place" byte
On 26 September 2018 at 08:38, Thomas Huth wrote:
> The IplParameterBlock and QemuIplParameters structures are declared
> with QEMU_PACKED, so the compiler assumes that the structures do not
> need to be aligned in memory. Since the are listed after a "bool"
> within the S390IPLState, the
Hello,
Recently qemu started hanging when running fstests (xfstests) after
upgrading the guests kernel (linux) from 4.15.x to 4.16. Nothing else
changed in the host or guest, besides the kernel version in the guest.
Running fstests always hangs when running either the test generic/299
or
We can fit this nicely into less LOC, without harming readability.
Reviewed-by: Richard Henderson
Reviewed-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
target/s390x/translate.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git
1 - 100 of 230 matches
Mail list logo
