The following changes since commit 9fc87111005e8903785db40819af66b8f85b8b96:
Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200717' into
staging (2020-07-19 10:29:05 +0100)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-5.1-20200720
for
From: Reza Arbab
NUMA nodes corresponding to GPU memory currently have the same
affinity/distance as normal memory nodes. Add a third NUMA associativity
reference point enabling us to give GPU nodes more distance.
This is guest visible information, which shouldn't change under a
running guest
From: Greg Kurz
Some recent error handling cleanups unveiled issues with our support of
PCI bridges:
1) QEMU aborts when using non-standard PCI bridge types,
unveiled by commit 7ef1553dac "spapr_pci: Drop some dead error handling"
$ qemu-system-ppc64 -M pseries -device pcie-pci-bridge
From: Greg Kurz
QEMU aborts with -device pnv-psi-POWER8:
$ qemu-system-ppc64 -device pnv-psi-POWER8
qemu-system-ppc64: hw/intc/xics.c:605: ics_realize: Assertion
`ics->xics' failed.
Aborted (core dumped)
The Processor Service Interface Controller is an internal device.
It should only be
Jason Wang 于2020年7月20日周一 下午12:00写道：
>
>
> On 2020/7/17 下午11:46, Li Qiang wrote:
> > Jason Wang 于2020年7月17日周五 下午1:39写道：
> >>
> >> On 2020/7/17 下午12:46, Li Qiang wrote:
> >>> Jason Wang 于2020年7月17日周五 上午11:10写道：
> On 2020/7/17 上午12:14, Li Qiang wrote:
> > Alexander Bulekov reported a UAF
On 2020/7/17 下午10:18, Peter Xu wrote:
On Thu, Jul 16, 2020 at 10:54:31AM +0800, Jason Wang wrote:
On 2020/7/16 上午9:00, Peter Xu wrote:
On Mon, Jul 13, 2020 at 12:04:16PM +0800, Jason Wang wrote:
On 2020/7/10 下午9:30, Peter Xu wrote:
On Fri, Jul 10, 2020 at 02:34:11PM +0800, Jason Wang
On 2020/7/17 下午11:52, Peter Maydell wrote:
On Fri, 17 Jul 2020 at 04:11, Jason Wang wrote:
I think several things were missed in this patch (take virtio-net as a
reference), do we need the following things:
- Cancel the bh when VM is stopped.
Similarly, what should we do with the bh when
On 2020/7/17 下午11:46, Li Qiang wrote:
Jason Wang 于2020年7月17日周五 下午1:39写道：
On 2020/7/17 下午12:46, Li Qiang wrote:
Jason Wang 于2020年7月17日周五 上午11:10写道：
On 2020/7/17 上午12:14, Li Qiang wrote:
Alexander Bulekov reported a UAF bug related e1000e packets send.
On 2020/7/18 上午12:12, Alex Williamson wrote:
On Thu, 16 Jul 2020 16:32:30 +0800
Yan Zhao wrote:
On Thu, Jul 16, 2020 at 12:16:26PM +0800, Jason Wang wrote:
On 2020/7/14 上午7:29, Yan Zhao wrote:
hi folks,
we are defining a device migration compatibility interface that helps upper
layer
On 200720 0754, P J P wrote:
> +-- On Fri, 17 Jul 2020, Li Qiang wrote --+
> | P J P 于2020年7月17日周五 下午5:09写道：
> | > @Alex, would it be possible to share the reproduces on the upstream bug
> | > LP#1886362?
> |
> | Maybe you mean the reproducer of your patch?
>
> Yes.
>
> | If you or Alex could
Fix a typo in an error message for KVM_SET_IRQCHIP ioctl:
"KVM_GET_IRQCHIP" should be "KVM_SET_IRQCHIP".
Signed-off-by: Kenta Ishiguro
---
hw/i386/kvm/ioapic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/kvm/ioapic.c b/hw/i386/kvm/ioapic.c
index
+-- On Fri, 17 Jul 2020, Li Qiang wrote --+
| P J P 于2020年7月17日周五 下午5:09写道：
| > @Alex, would it be possible to share the reproduces on the upstream bug
| > LP#1886362?
|
| Maybe you mean the reproducer of your patch?
Yes.
| If you or Alex could share it, I'm glad to analysis this issue.
** Attachment added: "source"
https://bugs.launchpad.net/qemu/+bug/1888165/+attachment/5394190/+files/loopnzbug.asm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888165
Title:
loopz/loopnz
** Attachment added: "bootable image demonstrating bug"
https://bugs.launchpad.net/qemu/+bug/1888165/+attachment/5394189/+files/loopnzbug.img
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888165
Public bug reported:
If you run QBasic in qemu, printing a double-type single-digit number
will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that
does not appear when running on a real CPU (or on qemu with -enable-
kvm). I tracked this down to the state of the status flags after
Sven Schnelle (sv...@stackframe.org) noticed that increasing
-#define TCG_MAX_TEMPS 512
+#define TCG_MAX_TEMPS 1024
in include/tcg/tcg.h prevents fixes that crash.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Your pipeline has failed.
Project: QEMU ( https://gitlab.com/qemu-project/qemu )
Branch: master ( https://gitlab.com/qemu-project/qemu/-/commits/master )
Commit: 9fc87111 (
https://gitlab.com/qemu-project/qemu/-/commit/9fc87111005e8903785db40819af66b8f85b8b96
)
Commit Message: Merge
On Fri, 17 Jul 2020 at 19:16, Richard Henderson
wrote:
>
> The following changes since commit 95d1fbabae0cd44156ac4b96d512d143ca7dfd5e:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/fixes-20200716-pull-request' into staging (2020-07-16
> 18:50:51 +0100)
>
> are available in the Git
On Fri, Jul 17, 2020 at 09:26:50PM -, Helge Deller wrote:
> Test still crashes the VM and chroot with up-to-date debian chroot,
> including updated gcc-9.3.0-14.
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
>
Hi Philippe,
Am 2020-07-18 11:37, schrieb Philippe Mathieu-Daudé:
The last microcode word (address 0x6000.6ffc) is not reachable.
Correct the programmable FPU I/O size (which is 4 KiB) to be
able to use all the microcode area.
Signed-off-by: Philippe Mathieu-Daudé
---
Rename function v9fs_readdir_data_size() -> v9fs_readdir_response_size()
and make it callable from other units. So far this function is only
used by 9p.c, however subsequent patches require the function to be
callable from another 9pfs unit. And as we're at it; also make it clear
for what this
Previous patch suggests that it might make sense to use a different mutex
type now while handling readdir requests, depending on the precise
protocol variant, as v9fs_do_readdir_with_stat() (used by 9P2000.u) uses
a CoMutex to avoid deadlocks that might happen with QemuMutex otherwise,
whereas
Make top half really top half and bottom half really bottom half:
Each T_readdir request handling is hopping between threads (main
I/O thread and background I/O driver threads) several times for
every individual directory entry, which sums up to huge latencies
for handling just a single T_readdir
As previously mentioned, I was investigating performance issues with 9pfs.
Raw file read/write of 9pfs is actually quite good, provided that client
picked a reasonable high msize (maximum message size). I would recommend
to log a warning on 9p server side if a client attached with a small msize
As we just fixed a severe performance issue with Treaddir request
handling, clarify this overall issue as a comment on
v9fs_co_run_in_worker() with the intention to hopefully prevent
such performance mistakes in future (and fixing other yet
outstanding ones).
Signed-off-by: Christian Schoenebeck
The previous, already existing 'basic' readdir test simply used a
'count' parameter big enough to retrieve all directory entries with a
single Treaddir request.
In the 3 new 'split' readdir tests added by this patch, directory
entries are retrieved, split over several Treaddir requests by picking
The newly added function v9fs_co_readdir_many() retrieves multiple
directory entries with a single fs driver request. It is intended to
replace uses of v9fs_co_readdir(), the latter only retrives a single
directory entry per fs driver request instead.
The reason for this planned replacement is
On 7/17/20 11:35 AM, Roman Bolshakov wrote:
> dtrace USDT is fully supported since OS X 10.6. There are a few
> peculiarities compared to other dtrace flavors.
>
> 1. It doesn't accept empty files.
> 2. It doesn't recognize bool type but accepts C99 _Bool.
> 3. It converts int8_t * in probe
Patchew URL: https://patchew.org/QEMU/20200719134329.21613-1-f4...@amsat.org/
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 ===
#!
Patchew URL: https://patchew.org/QEMU/20200719134329.21613-1-f4...@amsat.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200719134329.21613-1-f4...@amsat.org
Subject: [PATCH-for-5.1] qdev: Allow to create hotplug
Commit 510ef98dca made qdev_realize() support bus-less devices,
asserting either the device is bus-less or the device is created
on a bus. Commit 464a22c757 used qdev_realize() instead of
object_property_set_bool(). Since qdev_realize() now checks for
a bus, it is not possible to create hotplug
On Mon, Jul 6, 2020 at 10:54 AM Linus Walleij wrote:
> Ted, can you merge this patch?
>
> It seems QEMU is happy and AFICT it uses the approach you want :)
Gentle ping!
Yours,
Linus Walleij
Patchew URL:
https://patchew.org/QEMU/20200719122059.59843-1-mlevi...@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
Test that we can't write-share raw luks images by default,
but we still can with share-rw=on
Signed-off-by: Maxim Levitsky
---
tests/qemu-iotests/296 | 44 +-
tests/qemu-iotests/296.out | 12 +--
2 files changed, 53 insertions(+), 3 deletions(-)
My commit 'block/crypto: implement the encryption key management'
accidently allowed raw luks images to be shared between different
qemu processes without share-rw=on explicit override.
Fix that.
Fixes: bbfdae91fb ("block/crypto: implement the encryption key management")
Bugzilla:
A rebase gone wrong, and I ended up allowing a luks image
to be opened at the same time by two VMs without any warnings/overrides.
Fix that and also add an iotest to prevent this from happening.
Best regards,
Maxim Levisky
Maxim Levitsky (2):
block/crypto: disallow write sharing by
I just had a bunch of iotests fail on a freebsd VM test run.
I think the machine the VM runs on is sometimes a bit heavily
loaded for I/O, which means the VM can run slowly. This causes
various over-optimistic timeouts in the iotest testsuite to
spuriously fail. I also saw the 030 failure on the
Ottavio Caruso, le dim. 19 juil. 2020 12:07:21 +0100, a ecrit:
> On Sun, 19 Jul 2020 at 03:50, Samuel Thibault wrote:
> > Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> > > I cannot get traceroute to work with standard udp from any of my
> > > guests.
> > >
> > > $ traceroute
On Fri, 17 Jul 2020 at 17:48, Corey Minyard wrote:
>
> The following changes since commit 95d1fbabae0cd44156ac4b96d512d143ca7dfd5e:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/fixes-20200716-pull-request' into staging (2020-07-16
> 18:50:51 +0100)
>
> are available in the Git
David Carlier (3):
configure: fix for SunOS based systems.
exec: posix_madvise usage on SunOS.
contrib: ivshmem client and server build fix for SunOS.
configure | 2 +-
contrib/ivshmem-client/ivshmem-client.c | 12 ++--
40 matches
Mail list logo
