Hi Francisco,
On Thu, Dec 3, 2020 at 4:38 PM Francisco Iglesias
wrote:
>
> Hi Bin and Alistair,
>
> On [2020 Dec 02] Wed 11:40:11, Alistair Francis wrote:
> > On Sun, Nov 29, 2020 at 6:55 PM Bin Meng wrote:
> > >
> > > From: Bin Meng
> > >
> > > SST flashes require a dummy byte after the addres
On Wed, Dec 2, 2020 at 4:18 PM Toke Høiland-Jørgensen
wrote:
> Jason Wang writes:
>
> > On 2020/11/19 下午7:13, Andrew Melnychenko wrote:
> >> This set of patches introduces the usage of eBPF for packet steering
> >> and RSS hash calculation:
> >> * RSS(Receive Side Scaling) is used to distribute
On Fri, 4 Dec 2020 11:11:13 +1100
David Gibson wrote:
> Greg has agreed to be co-maintainer of the ppc target and machines.
> This should avoid repeats of the problem we had in qemu-5.2 where a
> last minute fix was needed while I was on holiday.
>
> Signed-off-by: David Gibson
> ---
Acked-by
> The category of the virtio-pmem device is not set, put it into the 'storage'
> category.
>
> Signed-off-by: Gan Qixin
> ---
> Cc: Michael S. Tsirkin
> ---
> hw/virtio/virtio-pmem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/virtio/virtio-pmem.c b/hw/virtio/virtio-pmem.c
> inde
Here is the output of the steps I tried:
root@11:~# cat /proc/sys/fs/binfmt_misc/qemu-s390x
enabled
interpreter /usr/bin/qemu-s390x-static
flags: F
offset 0
magic 7f454c46020201020016
mask ff00fffe
debootstrap --arch=s390x --foreign sid chroot-
> mdc->get_memory_region = pc_dimm_md_get_memory_region;
> > > mdc->fill_device_info = pc_dimm_md_fill_device_info;
> > > +set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
> >
> > Any reason why pc-dimm would be in the storage category?
...
> Thanks for you reply. As far as I know,
On 03.12.2020 19:56, Cleber Rosa wrote:
On Thu, Dec 03, 2020 at 09:29:10AM +0300, Pavel Dovgalyuk wrote:
On 02.12.2020 18:22, John Snow wrote:
On 12/2/20 1:31 AM, Pavel Dovgalyuk wrote:
This patch adds timeout parameter to vm.wait() calls,
because the default
value is just 30 seconds, and tes
Hi,
> > +case VNC_ENCODING_DESKTOP_RESIZE_EXT:
> > +vs->features |= VNC_FEATURE_RESIZE_EXT_MASK;
>
> IIUC, we shouldn't set this flag unless all current displays adapters
> associated with the VNC server support the "ui_info" callbacks,
> otherwise the client will think it c
On 03.12.2020 19:14, Peter Maydell wrote:
On Thu, 3 Dec 2020 at 16:10, Pavel Dovgalyuk wrote:
On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
Cc'ing Pavel
On 12/1/20 4:55 PM, Peter Maydell wrote:
On Wed, 25 Nov 2020 at 04:06, Richard Henderson
wrote:
As reported in https://bugs.launch
[ add linux-cxl for the Linux driver question ]
On Thu, Dec 3, 2020 at 9:10 PM Chris Browy wrote:
[..]
I'll let Ben address the other questions...
> 4. What are the userspace system APIs for targeting CXL HDM address domain?
>Usually you can mmap a SPA if you know how to look it up.
tl;dr
Currently the "memory-encryption" property is only looked at once we
get to kvm_init(). Although protection of guest memory from the
hypervisor isn't something that could really ever work with TCG, it's
not conceptually tied to the KVM accelerator.
In addition, the way the string property is reso
At least some s390 cpu models support "Protected Virtualization" (PV),
a mechanism to protect guests from eavesdropping by a compromised
hypervisor.
This is similar in function to other mechanisms like AMD's SEV and
POWER's PEF, which are controlled bythe "securable-guest-memory" machine
option.
This allows failures to be reported richly and idiomatically.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/kvm/kvm-all.c | 4 +++-
accel/kvm/sev-stub.c | 5 +++--
include/sysemu/sev.h | 2 +-
target/i386/sev.c| 31
While we've abstracted some (potential) differences between mechanisms for
securing guest memory, the initialization is still specific to SEV. Given
that, move it into x86's kvm_arch_init() code, rather than the generic
kvm_init() code.
Signed-off-by: David Gibson
---
accel/kvm/kvm-all.c | 14 -
Some upcoming POWER machines have a system called PEF (Protected
Execution Facility) which uses a small ultravisor to allow guests to
run in a way that they can't be eavesdropped by the hypervisor. The
effect is roughly similar to AMD SEV, although the mechanisms are
quite different.
Most of the
The kvm_memcrypt_enabled() and kvm_memcrypt_encrypt_data() helper functions
don't conceptually have any connection to KVM (although it's not possible
in practice to use them without it).
They also rely on looking at the global KVMState. But the same information
is available from the machine, and
The default behaviour for virtio devices is not to use the platforms normal
DMA paths, but instead to use the fact that it's running in a hypervisor
to directly access guest memory. That doesn't work if the guest's memory
is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
The platform specific details of mechanisms for implementing securable
guest memory may require setup at various points during initialization.
Thus, it's not really feasible to have a single sgm initialization hook,
but instead each mechanism needs its own initialization calls in arch or
machine sp
From: Greg Kurz
Global properties have an @optional field, which allows to apply a given
property to a given type even if one of its subclasses doesn't support
it. This is especially used in the compat code when dealing with the
"disable-modern" and "disable-legacy" properties and the "virtio-pci
We haven't yet implemented the fairly involved handshaking that will be
needed to migrate PEF protected guests. For now, just use a migration
blocker so we get a meaningful error if someone attempts this (this is the
same approach used by AMD SEV).
Signed-off-by: David Gibson
Reviewed-by: Dr. Da
At the moment AMD SEV sets a special function pointer, plus an opaque
handle in KVMState to let things know how to encrypt guest memory.
Now that we have a QOM interface for handling things related to securable
guest memory, use a QOM method on that interface, rather than a bare
function pointer f
When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.
We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property th
Several architectures have mechanisms which are designed to protect guest
memory from interference or eavesdropping by a compromised hypervisor. AMD
SEV does this with in-chip memory encryption and Intel's MKTME can do
similar things. POWER's Protected Execution Framework (PEF) accomplishes a
sim
A number of hardware platforms are implementing mechanisms whereby the
hypervisor does not have unfettered access to guest memory, in order
to mitigate the security impact of a compromised hypervisor.
AMD's SEV implements this with in-cpu memory encryption, and Intel has
its own memory encryption
Philippe Mathieu-Daudé 于2020年12月3日周四 下午8:38写道：
>
> On 12/3/20 1:02 PM, Li Qiang wrote:
> > Philippe Mathieu-Daudé 于2020年12月3日周四 下午7:37写道：
> >>
> >> Hi Li,
> >>
> >> On 12/3/20 12:21 PM, Li Qiang wrote:
> >>> Philippe Mathieu-Daudé 于2020年12月2日周三 上午3:13写道：
>
> cdb_len can not be zero...
There is an interesting typo in the help message of pcie_aer_inject_error
command. Use 'tlp' instead of 'tlb' to match the PCIe AER term.
Signed-off-by: Zenghui Yu
---
hmp-commands.hx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index
There is an obvious typo in the function name of the .log_sync() callback.
Spell it correctly.
Signed-off-by: Zenghui Yu
---
hw/vfio/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 6ff1daa763..d360d6f2da 100644
--- a/hw/v
Hi folks,
Here are a couple of procedural announcements about the qemu ppc
target.
First, I'm pleased to introduce Greg Kurz as co-maintainer, he's been
a contributor and common reviewed for the ppc target code in qemu for
some time. With him as co-maintainer we should have a bit more
redundancy
Greg has agreed to be co-maintainer of the ppc target and machines.
This should avoid repeats of the problem we had in qemu-5.2 where a
last minute fix was needed while I was on holiday.
Signed-off-by: David Gibson
---
MAINTAINERS | 17 -
1 file changed, 16 insertions(+), 1 delet
Patchew URL: https://patchew.org/QEMU/20201203234857.21051-1-ag...@csgraf.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20201203234857.21051-1-ag...@csgraf.de
Subject: [PATCH v4 00/11] hvf: Implement Apple Silicon
Now that we have working system register sync, we push more target CPU
properties into the virtual machine. That might be useful in some
situations, but is not the typical case that users want.
So let's add a -cpu host option that allows them to explicitly pass all
CPU capabilities of their host C
From: Peter Collingbourne
Sleep on WFI until the VTIMER is due but allow ourselves to be woken
up on IPI.
In this implementation IPI is blocked on the CPU thread at startup and
pselect() is used to atomically unblock the signal and begin sleeping.
The signal is sent unconditionally so there's no
With Apple Silicon available to the masses, it's a good time to add support
for driving its virtualization extensions from QEMU.
This patch adds all necessary architecture specific code to get basic VMs
working. It's still pretty raw, but definitely functional.
Known limitations:
- Vtimer ackn
We will need more than a single field for hvf going forward. To keep
the global vcpu struct uncluttered, let's allocate a special hvf vcpu
struct, similar to how hax does it.
Signed-off-by: Alexander Graf
Reviewed-by: Roman Bolshakov
Tested-by: Roman Bolshakov
---
accel/hvf/hvf-cpus.c|
We currently only support GICv2 emulation. To also support GICv3, we will
need to pass a few system registers into their respective handler functions.
This patch adds handling for all of the required system registers, so that
we can run with more than 8 vCPUs.
Signed-off-by: Alexander Graf
---
Now that we have all logic in place that we need to handle Hypervisor.framework
on Apple Silicon systems, let's add CONFIG_HVF for aarch64 as well so that we
can build it.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Fix build on 32bit arm
v3 -> v4:
- Remove i386-softmmu target
---
mes
Until now, Hypervisor.framework has only been available on x86_64 systems.
With Apple Silicon shipping now, it extends its reach to aarch64. To
prepare for support for multiple architectures, let's move common code out
into its own accel directory.
Signed-off-by: Alexander Graf
---
v3 -> v4:
The hooks we have that call us after reset, init and loadvm really all
just want to say "The reference of all register state is in the QEMU
vcpu struct, please push it".
We already have a working pushing mechanism though called cpu->vcpu_dirty,
so we can just reuse that for all of the above, synci
Now that Apple Silicon is widely available, people are obviously excited
to try and run virtualized workloads on them, such as Linux and Windows.
This patch set implements a fully functional version to get the ball
going on that. With this applied, I can successfully run both Linux and
Windows as
In Hypervisor.framework, we just pass PSCI calls straight on to the QEMU
emulation
of it. That means, if TCG is compatible with PSCI 0.2, so are we. Let's
transpose
that fact in code too.
Signed-off-by: Alexander Graf
---
v3 -> v4:
- Combine both if statements
---
target/arm/cpu.c | 4 ++-
In macOS 11, QEMU only gets access to Hypervisor.framework if it has the
respective entitlement. Add an entitlement template and automatically self
sign and apply the entitlement in the build.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Make safe to ctrl-C
v3 -> v4:
- Remove unused exe
The hvf i386 has a few struct and cpp definitions that are never
used. Remove them.
Suggested-by: Roman Bolshakov
Signed-off-by: Alexander Graf
---
target/i386/hvf/hvf-i386.h | 16
1 file changed, 16 deletions(-)
diff --git a/target/i386/hvf/hvf-i386.h b/target/i386/hvf/hvf-i3
On Thu, Dec 03, 2020 at 11:13:35PM +0100, Alexander Graf wrote:
>
> On 03.12.20 19:42, Peter Collingbourne wrote:
> > On Thu, Dec 3, 2020 at 1:41 AM Roman Bolshakov
> > wrote:
> > > On Mon, Nov 30, 2020 at 04:00:11PM -0800, Peter Collingbourne wrote:
> > > > What I observe is that when returning
Move bdrv_is_inserted() calls into callers.
We are going to make bdrv_check_byte_request() a clean thing.
bdrv_is_inserted() is not about checking the request, it's about
checking the bs. So, it should be separate.
With this patch we probably change error path for some failure
scenarios. But depe
We should not set overlap_bytes:
1. Don't worry: it is calculated by bdrv_mark_request_serialising() and
will be equal to or greater than bytes anyway.
2. If the request was already aligned up to some greater alignment,
than we may break things: we reduce overlap_bytes, and further
bdrv_
We are going to modify block layer to work with 64bit requests. And
first step is moving to int64_t type for both offset and bytes
arguments in all block request related functions.
It's mostly safe (when widening signed or unsigned int to int64_t), but
switching from uint64_t is questionable.
So,
This simplifies following commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/io.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/block/io.c b/block/io.c
index ec5e152bb7..3e91074c9f 100644
--- a/block/io.c
+++ b/block/io.c
@@ -135,10 +135,10 @@ static void
Hi all!
This is a preparation series for v4 of "[PATCH v3 00/17] 64bit
block-layer".
The whole thing is in 04, and 01-03 are small preparations.
Vladimir Sementsov-Ogievskiy (4):
block/file-posix: fix workaround in raw_do_pwrite_zeroes()
block/io: bdrv_refresh_limits(): use ERRP_GUARD
bloc
On 03.12.20 19:42, Peter Collingbourne wrote:
On Thu, Dec 3, 2020 at 1:41 AM Roman Bolshakov wrote:
On Mon, Nov 30, 2020 at 04:00:11PM -0800, Peter Collingbourne wrote:
On Mon, Nov 30, 2020 at 3:18 PM Alexander Graf wrote:
On 01.12.20 00:01, Peter Collingbourne wrote:
On Mon, Nov 30, 202
On Thu, Dec 03, 2020 at 03:25:17PM +0200, Andrew Melnychenko wrote:
> From: Andrew
>
> Added AER capability for virtio-pci devices.
> Also added property for devices, by default AER is disabled.
>
> Signed-off-by: Andrew Melnychenko
> ---
> hw/virtio/virtio-pci.c | 16
> hw/vi
> On Dec 3, 2020, at 4:53 AM, Stefan Hajnoczi wrote:
>
> On Tue, Dec 01, 2020 at 03:22:35PM -0500, Jagannathan Raman wrote:
>> This is the v12 of the patchset. Thank you very much for the
>> review of the v11 of the series.
>
> I'm in favor of merging this for QEMU 6.0. The command-line inte
On Thu, 3 Dec 2020 at 09:51, Stefan Hajnoczi wrote:
>
> On Tue, Dec 01, 2020 at 03:22:35PM -0500, Jagannathan Raman wrote:
> > This is the v12 of the patchset. Thank you very much for the
> > review of the v11 of the series.
>
> I'm in favor of merging this for QEMU 6.0. The command-line interface
On 12/3/20 7:14 PM, Thomas Huth wrote:
> On 03/12/2020 19.11, Philippe Mathieu-Daudé wrote:
>> On 12/3/20 6:22 PM, Thomas Huth wrote:
>>> On 03/12/2020 16.39, Cornelia Huck wrote:
Hotplug a virtio-net-ccw device, and then hotunplug it again.
>>>
>>> Good idea! ... is it also possible with a pc
time element is deprecated on new input_event structure in kernel's
input.h [1]
This will avoid the following build failure:
hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no member
named 'time'
Seems perfectly doable, no objections.
It will probably take me longer to integrate it in the build system
then to get the scripts ready.
I will start by placing the ruby tool and documentation there, and
later on, integrate it in the build system.
Hope that you get re-motivated to review our patc
On 12/3/20 10:54 AM, Cupertino Miranda wrote:
> Our generation tool has different levels of verbosity, expressing
> instruction semantics from a pattern level up to what it is shown in
> as comments, which is later converted to TCG format.
> For QEMU purposes I would say that input format should b
On Thu, Dec 03, 2020 at 09:14:04AM +, Stefan Hajnoczi wrote:
> On Tue, Dec 01, 2020 at 03:22:35PM -0500, Jagannathan Raman wrote:
> > This is the v12 of the patchset. Thank you very much for the
> > review of the v11 of the series.
>
> I'm in favor of merging this for QEMU 6.0. The command-lin
02.12.2020 21:18, Andrey Shinkevich wrote:
On 27.10.2020 21:24, Andrey Shinkevich wrote:
On 27.10.2020 20:57, Vladimir Sementsov-Ogievskiy wrote:
27.10.2020 20:48, Andrey Shinkevich wrote:
On 27.10.2020 19:13, Vladimir Sementsov-Ogievskiy wrote:
22.10.2020 21:13, Andrey Shinkevich wrote:
This module emulates control registers of versal usb2 controller, this is added
just to make guest happy. In general this module would control the phy-reset
signal from usb controller, data coherency of the transactions, signals
the host system errors received from controller.
Signed-off-by: Sai P
From: Vikram Garhwal
Connect VersalUsb2 subsystem to xlnx-versal SOC, its placed
in iou of lpd domain and configure it as dual port host controller.
Add the respective guest dts nodes for "xlnx-versal-virt" machine.
Signed-off-by: Vikram Garhwal
Signed-off-by: Sai Pavan Boddu
Reviewed-by: Edga
This patch series adds dwc3 usb controller to versal SOC.
Changes for V2:
Make XHCIState non-qom
Use container_of functions for retriving pci device instance
Initialize the AddressSpace pointer in PATCH 1/3 itself Changes for V3:
Convert XHCIState to TYPE_DEVICE and register as a c
From: Vikram Garhwal
This patch adds skeleton model of dwc3 usb controller attached to
xhci-sysbus device. It defines global register space of DWC3 controller,
global registers control the AXI/AHB interfaces properties, external FIFO
support and event count support. All of which are unimplemented
This model is a top level integration wrapper for hcd-dwc3 and
versal-usb2-ctrl-regs modules, this is used by xilinx versal soc's and
future xilinx usb subsystems would also be part of it.
Signed-off-by: Sai Pavan Boddu
Reviewed-by: Edgar E. Iglesias
Reviewed-by: Peter Maydell
---
hw/usb/Kconf
Hi Peter/Edgar,
> -Original Message-
> From: Edgar E. Iglesias
> Sent: Thursday, December 3, 2020 11:35 PM
> To: Peter Maydell
> Cc: Sai Pavan Boddu ; Markus Armbruster
> ; Marc-André Lureau ;
> Paolo Bonzini ; Gerd Hoffmann ;
> Edgar Iglesias ; Francisco Eduardo Iglesias
> ; Alistair Fr
02.12.2020 21:31, Andrey Shinkevich wrote:
Avoid writing a filter JSON file name and a filter format name to QCOW2
image when the backing file is being changed after the block stream
job. It can occur due to a concurrent commit job on the same backing
chain.
A user is still able to assign the 'ba
On Thu, Dec 3, 2020 at 1:41 AM Roman Bolshakov wrote:
>
> On Mon, Nov 30, 2020 at 04:00:11PM -0800, Peter Collingbourne wrote:
> > On Mon, Nov 30, 2020 at 3:18 PM Alexander Graf wrote:
> > >
> > >
> > > On 01.12.20 00:01, Peter Collingbourne wrote:
> > > > On Mon, Nov 30, 2020 at 1:40 PM Alexande
On Thu, Dec 3, 2020 at 2:12 AM Roman Bolshakov wrote:
>
> On Tue, Dec 01, 2020 at 10:59:50AM -0800, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 3:16 AM Alexander Graf wrote:
> > >
> > > Hi Peter,
> > >
> > > On 01.12.20 09:21, Peter Collingbourne wrote:
> > > > Sleep on WFx until the VT
On Tue, Dec 01, 2020 at 11:34:25AM +, Peter Maydell wrote:
> On Tue, 1 Dec 2020 at 08:34, Sai Pavan Boddu
> wrote:
> >
> > From: Vikram Garhwal
> >
> > Connect VersalUbs2 subsystem to xlnx-versal SOC, its placed
>
> Typo : "VersalUSB2".
>
>
> > in iou of lpd domain and configure it as dua
On Thu, Dec 3, 2020 at 2:39 AM Roman Bolshakov wrote:
>
> On Wed, Dec 02, 2020 at 08:04:06PM +0100, Alexander Graf wrote:
> > From: Peter Collingbourne
> >
> > Sleep on WFI until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> > Signed-off-by: Peter Collingbourne
> > [agra
On Thu, Dec 03, 2020 at 07:10:37PM +0100, Paolo Bonzini wrote:
> On 03/12/20 18:52, Eduardo Habkost wrote:
> > On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
> > > On 03/12/20 16:15, Kevin Wolf wrote:
> > > > I don't think this is an intermediate state like Eduardo wants to have.
>
On 03/12/2020 19.11, Philippe Mathieu-Daudé wrote:
> On 12/3/20 6:22 PM, Thomas Huth wrote:
>> On 03/12/2020 16.39, Cornelia Huck wrote:
>>> Hotplug a virtio-net-ccw device, and then hotunplug it again.
>>
>> Good idea! ... is it also possible with a pci device?
>>
>>> Signed-off-by: Cornelia Huck
On 12/3/20 6:22 PM, Thomas Huth wrote:
> On 03/12/2020 16.39, Cornelia Huck wrote:
>> Hotplug a virtio-net-ccw device, and then hotunplug it again.
>
> Good idea! ... is it also possible with a pci device?
>
>> Signed-off-by: Cornelia Huck
>> ---
...
>> +exec_command_and_wait_for_pattern
On Thu, Dec 3, 2020 at 2:30 PM Cleber Rosa wrote:
>
> On Thu, Dec 03, 2020 at 05:02:33PM +, Daniel P. Berrangé wrote:
> > I think the problem with the Fedora acceptance is that we'll be constantly
> > chasing a moving target. Every URL we pick will go away 6-12 months later.
> > IOW, while the
On 03/12/20 18:52, Eduardo Habkost wrote:
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after yo
On 03/12/20 18:43, Kevin Wolf wrote:
I think I'd want to do step 2 and 3 combined, because converting
user-creatable objects to oc->configure means manually writing the
configure function that will be generated from QAPI in step 3. Writing
code just to throw it away isn't my favourite pastime.
Hi Peter,
> -Original Message-
> From: Peter Maydell
> Sent: Tuesday, December 1, 2020 4:57 PM
> To: Sai Pavan Boddu
> Cc: Markus Armbruster ; Marc-André Lureau
> ; Paolo Bonzini ;
> Gerd Hoffmann ; Edgar Iglesias ;
> Francisco Eduardo Iglesias ; Alistair Francis
> ; Eduardo Habkost ; Yin
Hi Peter,
> -Original Message-
> From: Peter Maydell
> Sent: Tuesday, December 1, 2020 4:56 PM
> To: Sai Pavan Boddu
> Cc: Markus Armbruster ; Marc-André Lureau
> ; Paolo Bonzini ;
> Gerd Hoffmann ; Edgar Iglesias ;
> Francisco Eduardo Iglesias ; Alistair Francis
> ; Eduardo Habkost ; Yi
On Thu, Dec 3, 2020 at 5:00 AM Andrew Melnychenko wrote:
>
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
So the bugzilla seems to be reporting that the NIC operstate is being
misreported when qemu has configured the link down. Based on the
description it isn't clear to me how thi
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
> On 03/12/20 16:15, Kevin Wolf wrote:
> > I don't think this is an intermediate state like Eduardo wants to have.
> > Creating the object, then setting properties, then realize [1] will fail
> > after your change. But keeping it workin
Am 03.12.2020 um 17:50 hat Paolo Bonzini geschrieben:
> On 03/12/20 16:15, Kevin Wolf wrote:
> > I don't think this is an intermediate state like Eduardo wants to have.
> > Creating the object, then setting properties, then realize [1] will fail
> > after your change. But keeping it working was the
On Thu, Dec 03, 2020 at 12:29:59PM -0500, Cleber Rosa wrote:
> On Thu, Dec 03, 2020 at 05:02:33PM +, Daniel P. Berrangé wrote:
> > I think the problem with the Fedora acceptance is that we'll be constantly
> > chasing a moving target. Every URL we pick will go away 6-12 months later.
> > IOW, w
On Thu, 3 Dec 2020 18:22:35 +0100
Thomas Huth wrote:
> On 03/12/2020 16.39, Cornelia Huck wrote:
> > Hotplug a virtio-net-ccw device, and then hotunplug it again.
>
> Good idea! ... is it also possible with a pci device?
It should be, I guess; it's not part of my normal test workflow,
however
Am 03.12.2020 um 08:50 hat Gan Qixin geschrieben:
> v1->v2:
>
> -Patch1:
> Add Paolo Bonzini reviewed tag and delete the .c suffix in the commit
> message.
>
> -Patch2:
> Add Paolo Bonzini reviewed tag and delete the .c suffix in the commit
> message.
>
> -Patch3:
> Delete the .c suf
On Thu, Dec 03, 2020 at 05:02:33PM +, Daniel P. Berrangé wrote:
> I think the problem with the Fedora acceptance is that we'll be constantly
> chasing a moving target. Every URL we pick will go away 6-12 months later.
> IOW, while the acceptance test pass today, in 6 months time they'll be
> fa
If bdrv_co_yield_to_drain() is called for draining a block node that
runs in a different AioContext, it keeps that AioContext locked while it
yields and schedules a BH in the AioContext to do the actual drain.
As long as executing the BH is the very next thing the event loop of the
node's AioConte
On 03/12/2020 16.39, Cornelia Huck wrote:
> Hotplug a virtio-net-ccw device, and then hotunplug it again.
Good idea! ... is it also possible with a pci device?
> Signed-off-by: Cornelia Huck
> ---
>
> This is on top of "tests/acceptance: enhance s390x devices test"
>
> ---
> tests/acceptance/
The drain functions assume that we hold the AioContext lock of the
drained block node. Make sure to actually take the lock.
Cc: qemu-sta...@nongnu.org
Fixes: eb94b81a94bce112e6b206df846c1551aaf6cab6
Signed-off-by: Kevin Wolf
---
blockdev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-
The conversion of qmp_block_resize() to coroutines exposed a preexisting
locking bug in the drain implementation that can cause deadlocks.
As it happens, fixing this bug reveals in turn that the locking in
qmp_block_resize() itself is incomplete, too.
Kevin Wolf (3):
block: Simplify qmp_block_r
To enable it, you need to set -accel kvm,x-precise-tsc=on,
and have a kernel that supports this feature.
Signed-off-by: Maxim Levitsky
---
accel/kvm/kvm-all.c | 28 +
include/sysemu/kvm.h | 1 +
target/i386/cpu.h | 1 +
target/i386/kvm.c | 140
The only thing that happens after the 'out:' label is blk_unref(blk).
However, blk = NULL in all of the error cases, so instead of jumping to
'out:', we can just return directly.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Kevin Wolf
---
blockdev.c | 7 +++
1 file changed, 3 insertions(+), 4 d
Signed-off-by: Maxim Levitsky
---
include/standard-headers/asm-x86/kvm_para.h | 1 +
linux-headers/asm-x86/kvm.h | 2 +
linux-headers/linux/kvm.h | 71 -
3 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/include/standard-headers
Note that to use this feature you need the kernel patches which are
posted to LKML and k...@vger.kernel.org
The feature is disabled by default, and can be enabled with
-accel kvm,x-precise-tsc=on.
I changed the TSC and TSC adjust read/write code to go though a special
function kvm_get_tsc/kvm_set
On 12/2/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Only decode MSA opcodes if MSA is present (implemented).
>
> Now than check_msa_access() will only be called if MSA is
> present, the only way to have MIPS_HFLAG_MSA unset is if
> MSA is disabled (bit CP0C5_MSAEn cleared, see previous
> commit).
On 12/2/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> We don't use ASE_MSA anymore (replaced by ase_msa_available()
> checking MSAP bit from CP0_Config3). Remove it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/mips-defs.h | 1 -
> target/mips/translate_init.c.inc | 8 ++
On 12/2/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Instead of accessing CP0_Config3 directly and checking
> the 'MSA Present' bit, introduce an explicit helper,
> making the code easier to read.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/internal.h | 6 ++
> target/mip
On 12/2/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> MSA presence is expressed by the MSAP bit of CP0_Config3.
> We don't need to check anything else.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/internal.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Ri
*** This bug is a duplicate of bug 1906693 ***
https://bugs.launchpad.net/bugs/1906693
** This bug has been marked a duplicate of bug 1906693
Assertion Failure in bdrv_co_write_req_prepare through megasas
--
You received this bug notification because you are a member of qemu-
devel-ml, wh
diff --git a/arch/arm64/include/asm/sysreg.h
b/arch/arm64/include/asm/sysreg.h
index e2ef4c2edf06..b6668ffa04d9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -569,7 +569,8 @@
#define SCTLR_ELx_M(BIT(0))
#define SCTLR_ELx_FLAGS(SCTLR_ELx_M
On 12/2/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Call msa_reset() inconditionally, but only reset
unconditionally.
> the MSA registers if MSA is implemented.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Maybe not very useful.
Yeah, it's marginal, especially given one user.
But whichev
On Thu, Dec 03, 2020 at 11:50:33AM -0500, Cleber Rosa wrote:
> On Thu, Dec 03, 2020 at 10:37:01AM +0100, Philippe Mathieu-Daudé wrote:
> > On 12/2/20 10:57 PM, Cleber Rosa wrote:
> > > Currently in use Fedora 31 has been moved out of the standard download
> > > locations that are supported by the f
1 - 100 of 256 matches
Mail list logo
