On 01.11.2019 18:09, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 12:34, Tuguoyi wrote:
> > On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote:
> >> 01.11.2019 10:37, Tuguoyi wrote:
> >>> There are two issues in In check_constraints_on_bitmap(),
> >>> 1) The sanity check on the granularity
Thanks!
2019年11月2日(土) 1:58 Palmer Dabbelt :
> On Tue, 29 Oct 2019 17:23:18 PDT (-0700), hiroyuki.obin...@gmail.com
> wrote:
> > From: "hiroyuki.obinata"
> >
> > Signed-off-by: Hiroyuki Obinata
> > ---
> > target/riscv/translate.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
On Fri, 01 Nov 2019 08:40:24 PDT (-0700), a...@brainfault.org wrote:
On Tue, Oct 29, 2019 at 6:55 PM Alistair Francis wrote:
On Fri, Oct 25, 2019 at 6:28 AM Anup Patel wrote:
>
> This series adds RTC device to QEMU RISC-V virt machine. We have
> selected Goldfish RTC device model for this. It
Hi Mark,
On Sat, Oct 26, 2019 at 07:54:40PM +0200, Sven Schnelle wrote:
> Hi Mark,
>
> On Sat, Oct 26, 2019 at 10:35:20AM +0100, Mark Cave-Ayland wrote:
>
> > > However, the VRAM in Artist is not really exposed to the Host. Instead,
> > > there's the Chipset inbetween that can do byte swapping (
Hi Taylor,
On 10/25/19 6:26 PM, Taylor Simpson wrote:
We would like inform the you that we will be doing a talk at the KVM
Forum next week on QEMU for Qualcomm Hexagon. Alessandro Di Federico,
Niccolo Izzo, and I have been working independently on implementations
of the Hexagon target. We pl
On Thu, Oct 24, 2019 at 08:34:28AM -0400, Liu Yi L wrote:
> This patch adds pci_device_iommu_context() to get an iommu_context
> for a given device. A new callback is added in PCIIOMMUOps. Users
> who wants to listen to events issued by vIOMMU could use this new
> interface to get an iommu_context
On Thu, Oct 24, 2019 at 08:34:27AM -0400, Liu Yi L wrote:
> This patch modifies pci_setup_iommu() to set PCIIOMMUOps instead of only
> setting PCIIOMMUFunc. PCIIOMMUFunc is previously used to get an address
> space for a device in vendor specific way. The PCIIOMMUOps still offers
> this functionali
On Thu, Oct 24, 2019 at 08:34:31AM -0400, Liu Yi L wrote:
> This patch adds virtual command support to Intel vIOMMU per
> Intel VT-d 3.1 spec. And adds two virtual commands: alloc_pasid
> and free_pasid.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Peter Xu
> Cc: Yi Sun
> Signed-off-by: Liu Yi L
On Tue, Oct 29, 2019 at 01:15:44PM +0100, David Gibson wrote:
> > +union IOMMUCTXPASIDReqDesc {
> > +struct {
> > +uint32_t min_pasid;
> > +uint32_t max_pasid;
> > +int32_t alloc_result; /* pasid allocated for the alloc request */
> > +};
> > +struct {
> > +
On Fri, Nov 01, 2019 at 10:55:29AM +0100, Christian Ehrhardt wrote:
> On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé
> wrote:
> >
> > On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> > > Hi everyone,
> > > we've got a bug report recently - on handling qemu .so's through
>
On Tue, 29 Oct 2019 23:54:30 PDT (-0700), alistai...@gmail.com wrote:
On Tue, Oct 29, 2019 at 4:14 PM Palmer Dabbelt wrote:
On Tue, 29 Oct 2019 03:49:23 PDT (-0700), alistai...@gmail.com wrote:
> On Fri, Oct 18, 2019 at 7:44 PM Alistair Francis wrote:
>>
>> On Fri, Oct 18, 2019 at 9:51 AM Pal
On Tue, 29 Oct 2019 17:23:18 PDT (-0700), hiroyuki.obin...@gmail.com wrote:
From: "hiroyuki.obinata"
Signed-off-by: Hiroyuki Obinata
---
target/riscv/translate.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index ad
While working on the Tulip driver i tried to write some Teledisk images to
a floppy image which didn't work. Turned out that Teledisk checks the written
data by issuing a READ command to the FDC but running the DMA controller
in VERIFY mode. As we ignored the DMA request in that case, the DMA trans
The test for an NBD client. The NBD server is disconnected after the
client write request. The NBD client should reconnect and complete
the write operation.
Suggested-by: Denis V. Lunev
Suggested-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Andrey Shinkevich
---
tests/qemu-iotests/277
01.11.2019 18:42, John Snow wrote:
> Hi, in one of my infamously unreadable and long status emails, I
> mentioned possibly wanting to copy allocation data into bitmaps as a way
> to enable users to create (external) snapshots from outside of the
> libvirt/qemu context.
>
> (That is: to repair chec
01.11.2019 18:49, Denis Lunev wrote:
> On 11/1/19 4:42 PM, John Snow wrote:
>> Hi, in one of my infamously unreadable and long status emails, I
>> mentioned possibly wanting to copy allocation data into bitmaps as a way
>> to enable users to create (external) snapshots from outside of the
>> libvir
The following changes since commit b7c9a7f353c0e260519bf735ff0d4aa01e72784b:
Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into
staging (2019-10-31 15:57:30 +)
are available in the Git repository at:
git://github.com/palmer-dabbelt/qemu.git tags/palmer-for-master-4
I'm leaving SiFive in a bit less than two weeks, which means I'll be
losing my @sifive email address. I don't have my new email address yet,
so I'm switching over to my personal address.
Reviewed-by: Alistair Francis
Signed-off-by: Palmer Dabbelt
Signed-off-by: Palmer Dabbelt
---
MAINTAINERS
On 11/1/19 4:49 PM, Denis V. Lunev wrote:
On 11/1/19 4:42 PM, John Snow wrote:
Hi, in one of my infamously unreadable and long status emails, I
mentioned possibly wanting to copy allocation data into bitmaps as a way
to enable users to create (external) snapshots from outside of the
libvirt/qemu
On 01.11.19 16:42, Kevin Wolf wrote:
> Am 01.11.2019 um 15:01 hat Max Reitz geschrieben:
>> On 01.11.19 13:40, Eric Blake wrote:
>>> On 11/1/19 11:00 AM, Max Reitz wrote:
This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
This commit causes fundamental performance problems
On 11/1/19 4:42 PM, John Snow wrote:
> Hi, in one of my infamously unreadable and long status emails, I
> mentioned possibly wanting to copy allocation data into bitmaps as a way
> to enable users to create (external) snapshots from outside of the
> libvirt/qemu context.
>
> (That is: to repair che
Patchew URL: https://patchew.org/QEMU/20191101152510.11719-1-mre...@redhat.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 BEGIN ===
#
Hi, in one of my infamously unreadable and long status emails, I
mentioned possibly wanting to copy allocation data into bitmaps as a way
to enable users to create (external) snapshots from outside of the
libvirt/qemu context.
(That is: to repair checkpoints in libvirt after a user extended the
ba
Am 01.11.2019 um 15:01 hat Max Reitz geschrieben:
> On 01.11.19 13:40, Eric Blake wrote:
> > On 11/1/19 11:00 AM, Max Reitz wrote:
> >> This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
> >>
> >> This commit causes fundamental performance problems on XFS (because
> >> fallocate() stalls
On Tue, Oct 29, 2019 at 6:55 PM Alistair Francis wrote:
>
> On Fri, Oct 25, 2019 at 6:28 AM Anup Patel wrote:
> >
> > This series adds RTC device to QEMU RISC-V virt machine. We have
> > selected Goldfish RTC device model for this. It's a pretty simple
> > synthetic device with few MMIO registers
Make both bdrv_mark_request_serialising() and
bdrv_wait_serialising_requests() public so they can be used from block
drivers.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Reitz
---
include/block/block_int.h | 3 +++
block/io.c| 24
2 files changed, 15 i
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Reitz
---
include/block/block_int.h | 1 +
block/io.c| 18 ++
2 files changed, 19 insertions(+)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 32fa323b63..dd033d0b37 100644
--- a/include/bloc
The XFS kernel driver has a bug that may cause data corruption for qcow2
images as of qemu commit c8bb23cbdbe32f. We can work around it by
treating post-EOF fallocates as serializing up until infinity (INT64_MAX
in practice).
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Reitz
---
block/file-po
Hi,
As I reasoned here:
https://lists.nongnu.org/archive/html/qemu-block/2019-11/msg00027.html
I’m no longer convinced of reverting c8bb23cbdbe. I could see a
significant performance improvement from it on ext4 with aio=native in a
guest that does random 4k writes, and as such I feel it would be
On 01.11.19 14:30, Max Reitz wrote:
[...]
> So unless there are realistic guest benchmarks for ext4 that say we
> should keep the patch, I’m going to queue the revert for now (“now” =
> 4.1.1 and 4.2.0).
I found one case where the performance is significantly improved by
c8bb23cbdbe: In the case
On Thu, Oct 24, 2019 at 08:34:26AM -0400, Liu Yi L wrote:
[...]
> +typedef struct VFIOIOMMUContext {
> +VFIOContainer *container;
> +IOMMUContext *iommu_ctx;
> +IOMMUCTXNotifier n;
> +QLIST_ENTRY(VFIOIOMMUContext) iommu_ctx_next;
> +} VFIOIOMMUContext;
> +
No strong opinion on th
On Thu, Oct 24, 2019 at 08:34:24AM -0400, Liu Yi L wrote:
> Intel VT-d 3.0 introduces scalable mode, and it has a bunch of capabilities
> related to scalable mode translation, thus there are multiple combinations.
> While this vIOMMU implementation wants simplify it for user by providing
> typical
On Thu, Oct 24, 2019 at 08:34:29AM -0400, Liu Yi L wrote:
> This patch adds get_iommu_context() callback to return an iommu_context
> Intel VT-d platform.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Peter Xu
> Cc: Yi Sun
> Signed-off-by: Liu Yi L
> ---
> hw/i386/intel_iommu.c | 57
> ++
Jordi Pujol, le ven. 01 nov. 2019 15:38:19 +0100, a ecrit:
> +options = g_getenv("SMBDOPTIONS");
> +if (options) {
> +smb_cmdline = g_strdup_printf("%s %s", smb_cmdline, options);
> +}
> +g_free(options);
But then do not free it :)
Samuel
On Thu, Oct 31, 2019 at 11:50 PM Samuel Thibault
wrote:
> Why strduping it? you can just use g_getenv.
ACK, I have also placed the variable declaration after the others.
Here is the v3 of this patch.
**
From: Jordi Pujol Palomer
Da
On Fri, Nov 01, 2019 at 12:53:42PM +, Peter Maydell wrote:
> On Fri, 1 Nov 2019 at 10:34, Peter Maydell wrote:
> >
> > On Fri, 1 Nov 2019 at 09:54, Andrew Jones wrote:
> > > Darn it. Sorry about that, but if it's still failing then I think QEMU
> > > must believe KVM is enabled, i.e. kvm_enab
On 01.11.19 13:40, Eric Blake wrote:
> On 11/1/19 11:00 AM, Max Reitz wrote:
>> This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
>>
>> This commit causes fundamental performance problems on XFS (because
>> fallocate() stalls the AIO pipeline), and as such it is not clear that
>> we sho
On 01.11.19 14:36, Denis Lunev wrote:
> On 11/1/19 4:09 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 01.11.2019 15:34, Max Reitz wrote:
>>> On 01.11.19 12:20, Max Reitz wrote:
On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 14:12, Max Reitz wrote:
>> On 01.11.19 11:28
On 11/1/19 4:09 PM, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 15:34, Max Reitz wrote:
>> On 01.11.19 12:20, Max Reitz wrote:
>>> On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
01.11.2019 14:12, Max Reitz wrote:
> On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
>>
On 01.11.19 13:34, Max Reitz wrote:
> On 01.11.19 12:20, Max Reitz wrote:
>> On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
>>> 01.11.2019 14:12, Max Reitz wrote:
On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 13:20, Max Reitz wrote:
>> On 01.11.19 11:00, M
01.11.2019 15:34, Max Reitz wrote:
> On 01.11.19 12:20, Max Reitz wrote:
>> On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
>>> 01.11.2019 14:12, Max Reitz wrote:
On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 13:20, Max Reitz wrote:
>> On 01.11.19 11:00, Ma
On Fri, 1 Nov 2019 at 10:34, Peter Maydell wrote:
>
> On Fri, 1 Nov 2019 at 09:54, Andrew Jones wrote:
> > Darn it. Sorry about that, but if it's still failing then I think QEMU
> > must believe KVM is enabled, i.e. kvm_enabled() in QEMU must be true.
> > I can try to confirm that and fix it, but
On 11/1/19 11:00 AM, Max Reitz wrote:
This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
This commit causes fundamental performance problems on XFS (because
fallocate() stalls the AIO pipeline), and as such it is not clear that
we should unconditionally enable this behavior.
We expec
On 01.11.19 12:20, Max Reitz wrote:
> On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
>> 01.11.2019 14:12, Max Reitz wrote:
>>> On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
01.11.2019 13:20, Max Reitz wrote:
> On 01.11.19 11:00, Max Reitz wrote:
>> Hi,
>>
>> Th
On 11/1/19 6:54 AM, Hervé Poussineau wrote:
> Le 30/10/2019 à 09:28, Sven Schnelle a écrit :
>> While working on the Tulip driver i tried to write some Teledisk
>> images to
>> a floppy image which didn't work. Turned out that Teledisk checks the
>> written
>> data by issuing a READ command to t
On Wed, Oct 30, 2019 at 17:32:43 +0100, David Gibson wrote:
> We have to set the default model of all machine classes, not just for the
> active one. Otherwise, "query-machines" will indicate the wrong CPU model
> ("qemu-s390x-cpu" instead of "host-s390x-cpu") as "default-cpu-type".
>
> s390x alre
On Fri, Nov 1, 2019 at 11:35 AM Programmingkid
wrote:
>
> > On Oct 31, 2019, at 7:35 PM, qemu-devel-requ...@nongnu.org wrote:
> >
> > Message: 10
> > Date: Thu, 31 Oct 2019 18:39:11 -
> > From: John Canada <1850...@bugs.launchpad.net>
> > To: qemu-devel@nongnu.org
> > Subject: [Bug 1850570] R
Patchew URL:
https://patchew.org/QEMU/20191101103232.3692818-1-luc.mic...@greensocs.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 BE
Patchew URL:
https://patchew.org/QEMU/20191101103232.3692818-1-luc.mic...@greensocs.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 B
On 01.11.19 12:16, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 14:12, Max Reitz wrote:
>> On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
>>> 01.11.2019 13:20, Max Reitz wrote:
On 01.11.19 11:00, Max Reitz wrote:
> Hi,
>
> This series builds on the previous RFC. The wo
01.11.2019 14:12, Max Reitz wrote:
> On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
>> 01.11.2019 13:20, Max Reitz wrote:
>>> On 01.11.19 11:00, Max Reitz wrote:
Hi,
This series builds on the previous RFC. The workaround is now applied
unconditionally of AIO mode and fi
On 01.11.19 11:28, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 13:20, Max Reitz wrote:
>> On 01.11.19 11:00, Max Reitz wrote:
>>> Hi,
>>>
>>> This series builds on the previous RFC. The workaround is now applied
>>> unconditionally of AIO mode and filesystem because we don’t know those
>>> th
On 11/1/19 11:42 AM, Peter Maydell wrote:
> On Fri, 1 Nov 2019 at 10:32, Luc Michel wrote:
>>
>> This machine modifies the CPU state when simulating suspend mode. This
>> commit adds a missing call to arm_rebuild_hflags after those
>> modifications.
>>
>> Signed-off-by: Luc Michel
>> ---
>> I cam
Le 30/10/2019 à 09:28, Sven Schnelle a écrit :
While working on the Tulip driver i tried to write some Teledisk images to
a floppy image which didn't work. Turned out that Teledisk checks the written
data by issuing a READ command to the FDC but running the DMA controller
in VERIFY mode. As we ig
On Fri, 1 Nov 2019 at 10:32, Luc Michel wrote:
>
> This machine modifies the CPU state when simulating suspend mode. This
> commit adds a missing call to arm_rebuild_hflags after those
> modifications.
>
> Signed-off-by: Luc Michel
> ---
> I came over this missing hflags rebuild while reviewing E
> On Oct 31, 2019, at 7:35 PM, qemu-devel-requ...@nongnu.org wrote:
>
> Message: 10
> Date: Thu, 31 Oct 2019 18:39:11 -
> From: John Canada <1850...@bugs.launchpad.net>
> To: qemu-devel@nongnu.org
> Subject: [Bug 1850570] Re: Cannot use usb-host on Mac OS
> Message-ID:
> <157254715118.
On Fri, 1 Nov 2019 at 09:54, Andrew Jones wrote:
> Darn it. Sorry about that, but if it's still failing then I think QEMU
> must believe KVM is enabled, i.e. kvm_enabled() in QEMU must be true.
> I can try to confirm that and fix it, but I'll need to set up this
> environment first.
Yeah, it look
This machine modifies the CPU state when simulating suspend mode. This
commit adds a missing call to arm_rebuild_hflags after those
modifications.
Signed-off-by: Luc Michel
---
I came over this missing hflags rebuild while reviewing Edgar's similar
fix in hw/arm/boot.c. I could not find any other
01.11.2019 13:20, Max Reitz wrote:
> On 01.11.19 11:00, Max Reitz wrote:
>> Hi,
>>
>> This series builds on the previous RFC. The workaround is now applied
>> unconditionally of AIO mode and filesystem because we don’t know those
>> things for remote filesystems. Furthermore, bdrv_co_get_self_req
01.11.2019 13:00, Max Reitz wrote:
> This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
>
> This commit causes fundamental performance problems on XFS (because
> fallocate() stalls the AIO pipeline), and as such it is not clear that
> we should unconditionally enable this behavior.
>
>
On 01.11.19 11:00, Max Reitz wrote:
> Hi,
>
> This series builds on the previous RFC. The workaround is now applied
> unconditionally of AIO mode and filesystem because we don’t know those
> things for remote filesystems. Furthermore, bdrv_co_get_self_request()
> has been moved to block/io.c.
>
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> I forgot to Cc David and Daniel for this one.
>
> On 10/15/19 6:26 PM, Philippe Mathieu-Daudé wrote:
> > These devices implemented their load_state_old() handler 10 years
> > ago, previous to QEMU v0.12.
> > Since commit cc425b5ddf removed the
On Thu, Oct 31, 2019 at 23:02:45 +0100, Paolo Bonzini wrote:
> On 31/10/19 11:58, John Snow wrote:
> > It's an old compatibility shim that just delegates to ide-cd or ide-hd.
> > I'd like to refactor these some day, and getting rid of the super-object
> > will make that easier.
> >
> > Either way,
01.11.2019 12:34, Tuguoyi wrote:
> On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote:
>> 01.11.2019 10:37, Tuguoyi wrote:
>>> There are two issues in In check_constraints_on_bitmap(),
>>> 1) The sanity check on the granularity will cause uint64_t integer
>>> left-shift overflow when cluster_si
The XFS kernel driver has a bug that may cause data loss when using
fallocate() in an I/O path, i.e. writing zeroes. We can work around it
by treating post-EOF fallocates as serializing up until infinity
(INT64_MAX in practice).
Signed-off-by: Max Reitz
---
block/file-posix.c | 38 +
Make both bdrv_mark_request_serialising() and
bdrv_wait_serialising_requests() public so they can be used from block
drivers.
Signed-off-by: Max Reitz
---
include/block/block_int.h | 3 +++
block/io.c| 24
2 files changed, 15 insertions(+), 12 deletions(
Signed-off-by: Max Reitz
---
include/block/block_int.h | 1 +
block/io.c| 18 ++
2 files changed, 19 insertions(+)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 32fa323b63..4fc531f9b2 100644
--- a/include/block/block_int.h
+++ b/include
Hi,
This series builds on the previous RFC. The workaround is now applied
unconditionally of AIO mode and filesystem because we don’t know those
things for remote filesystems. Furthermore, bdrv_co_get_self_request()
has been moved to block/io.c.
Applying the workaround unconditionally is fine f
This reverts commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a.
This commit causes fundamental performance problems on XFS (because
fallocate() stalls the AIO pipeline), and as such it is not clear that
we should unconditionally enable this behavior.
We expect subclusters to alleviate the performan
On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé wrote:
>
> On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> > Hi everyone,
> > we've got a bug report recently - on handling qemu .so's through
> > upgrades - that got me wondering how to best handle it.
> > After checking wit
into
> > staging (2019-10-31 15:57:30 +)
> >
> > are available in the Git repository at:
> >
> > https://git.linaro.org/people/pmaydell/qemu-arm.git
> > tags/pull-target-arm-20191101-1
> >
> > for you to fetch changes up to d9ae7624b659362cb2bb2b04
On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 10:37, Tuguoyi wrote:
> > There are two issues in In check_constraints_on_bitmap(),
> > 1) The sanity check on the granularity will cause uint64_t integer
> > left-shift overflow when cluster_size is 2M and the granularity is
> >
On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> Hi everyone,
> we've got a bug report recently - on handling qemu .so's through
> upgrades - that got me wondering how to best handle it.
> After checking with Paolo yesterday that there is no obvious solution
> that I missed we
o.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20191101-1
>
> for you to fetch changes up to d9ae7624b659362cb2bb2b04fee53bf50829ca56:
>
> target/arm: Allow reading flags from FPSCR for M-profile (2019-11-01
> 08:49:10 +)
Drew, this is still failing 'make ch
01.11.2019 10:37, Tuguoyi wrote:
> There are two issues in In check_constraints_on_bitmap(),
> 1) The sanity check on the granularity will cause uint64_t
> integer left-shift overflow when cluster_size is 2M and the
> granularity is BIGGER than 32K.
> 2) The way to calculate image size that the max
From: Andrew Jones
Extend the SVE vq map initialization and validation with KVM's
supported vector lengths when KVM is enabled. In order to determine
and select supported lengths we add two new KVM functions for getting
and setting the KVM_REG_ARM64_SVE_VLS pseudo-register.
This patch has been c
From: "Edgar E. Iglesias"
Rebuild hflags when modifying CPUState at boot.
Fixes: e979972a6a
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Reviewed-by: Luc Michel
Message-id: 20191031040830.18800-2-edgar.igles...@xilinx.com
Signed-off-by: Peter
From: Andrew Jones
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bi
From: Christophe Lyon
rt==15 is a special case when reading the flags: it means the
destination is APSR. This patch avoids rejecting
vmrs apsr_nzcv, fpscr
as illegal instruction.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Christophe Lyon
Message-id: 20191025095711.10853-1-christophe.l...@linaro.
From: Andrew Jones
Now that Arm CPUs have advertised features lets add tests to ensure
we maintain their expected availability with and without KVM.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
Message-id: 20191031142734.8590-3-drjo...@redhat.com
Signed-off-by: Peter Maydell
---
tests
From: Andrew Jones
Allow cpu 'host' to enable SVE when it's available, unless the
user chooses to disable it with the added 'sve=off' cpu property.
Also give the user the ability to select vector lengths with the
sve properties. We don't adopt 'max' cpu's other sve property,
sve-max-vq, because t
From: Andrew Jones
These are the SVE equivalents to kvm_arch_get/put_fpsimd. Note, the
swabbing is different than it is for fpsmid because the vector format
is a little-endian stream of words.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayo
From: Andrew Jones
kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init
parameter. Rather than just using it as an output parameter to
pass back the preferred target, use it also as an input parameter,
allowing a caller to pass a selected target if they wish and to
also pass cpu featur
remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into
staging (2019-10-31 15:57:30 +)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20191101-1
for you to fetch cha
From: Andrew Jones
Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
a CPU property") we can disable the 'max' cpu model's VFP and neon
features, but there's no way to disable SVE. Add the 'sve=on|off'
property to give it that flexibility. We also rename
cpu_max_get/set_sve_
From: Andrew Jones
Add support for the query-cpu-model-expansion QMP command to Arm. We
do this selectively, only exposing CPU properties which represent
optional CPU features which the user may want to enable/disable.
Additionally we restrict the list of queryable cpu models to 'max',
'host', or
On Fri, Nov 01, 2019 at 12:07:01AM -0400, Michael S. Tsirkin wrote:
> Regarding the presentation I gave at the kvm forum
> on pagefaults.
>
> Two points:
>
>
> 1. pagefaults are important not just for migration.
> They are important for performance features such as
> autonuma and huge pages, sin
From: Andrew Jones
Enable SVE in the KVM guest when the 'max' cpu type is configured
and KVM supports it. KVM SVE requires use of the new finalize
vcpu ioctl, so we add that now too. For starters SVE can only be
turned on or off, getting all vector lengths the host CPU supports
when on. We'll add
On Fri, 25 Oct 2019 at 10:57, Christophe Lyon
wrote:
>
> rt==15 is a special case when reading the flags: it means the
> destination is APSR. This patch avoids rejecting
> vmrs apsr_nzcv, fpscr
> as illegal instruction.
>
> Signed-off-by: Christophe Lyon
> ---
> target/arm/translate-vfp.inc.c |
On Thu, 31 Oct 2019 at 04:08, Edgar E. Iglesias
wrote:
>
> I'm seeing asserts with missmatching hflags when doing direct boots
> on versal. This patch fixes the problem for me, rebuilding hflags
> after boot code modifes the state.
>
> Cheers,
> Edgar
>
> Edgar E. Iglesias (1):
> hw/arm/boot: Re
On 2019/11/1 下午4:04, Jason Wang wrote:
On 2019/11/1 下午3:46, Tian, Kevin wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Friday, November 1, 2019 3:30 PM
On 2019/10/31 下午10:07, Liu, Yi L wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, October 31, 2019 5:33 AM
* Vivek Goyal (vgo...@redhat.com) wrote:
> On Wed, Oct 23, 2019 at 09:25:23PM +0900, Misono Tomohiro wrote:
> > When writeback mode is enabled (-o writeback), O_APPEND handling is
> > done in kernel. Therefore virtiofsd clears O_APPEND flag when open.
> > Otherwise O_APPEND flag takes precedence ov
On 2019/11/1 下午3:46, Tian, Kevin wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Friday, November 1, 2019 3:30 PM
On 2019/10/31 下午10:07, Liu, Yi L wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, October 31, 2019 5:33 AM
Subject: Re: [RFC v2 00/22] intel_iommu:
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, November 1, 2019 3:30 PM
>
>
> On 2019/10/31 下午10:07, Liu, Yi L wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Thursday, October 31, 2019 5:33 AM
> >> Subject: Re: [RFC v2 00/22] intel_iommu: expose Shared Virtu
There are two issues in In check_constraints_on_bitmap(),
1) The sanity check on the granularity will cause uint64_t
integer left-shift overflow when cluster_size is 2M and the
granularity is BIGGER than 32K.
2) The way to calculate image size that the maximum bitmap
supported can map to is a bit i
On 2019/10/31 下午10:07, Liu, Yi L wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, October 31, 2019 5:33 AM
Subject: Re: [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM
On 2019/10/25 下午6:12, Tian, Kevin wrote:
From: Jason Wang [mailto:jasow...@redhat.com
Hi everyone,
we've got a bug report recently - on handling qemu .so's through
upgrades - that got me wondering how to best handle it.
After checking with Paolo yesterday that there is no obvious solution
that I missed we agreed this should be brought up on the list for
wider discussion.
Maybe there
On 01/11/19 06:40, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/10/19 11:58, John Snow wrote:
>>> It's an old compatibility shim that just delegates to ide-cd or ide-hd.
>>> I'd like to refactor these some day, and getting rid of the super-object
>>> will make that easier.
>>>
>>>
98 matches
Mail list logo
