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
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
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'
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
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 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, 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 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
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
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
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,
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_
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
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
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
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
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 ++-
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
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
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:
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
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
---
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|
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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
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 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
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
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 -
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
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.
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
[ 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
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
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: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
> 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,
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-
> 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
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
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
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
201 - 256 of 256 matches
Mail list logo
