On 2020/11/27 20:10, Markus Armbruster wrote:
> Zeyu Jin writes:
>
>> This patch enables zstd option in multi-thread compression.
>>
>> Signed-off-by: Zeyu Jin
>> Signed-off-by: Ying Fang
> [...]
>> diff --git a/qapi/migration.json b/qapi/migration.json
>> index d262683a38..ac6d06c683 100644
On 2020/11/27 17:48, Markus Armbruster wrote:
> Kevin, Max, suggest to skip right to Qcow2CompressionType.
>
> Zeyu Jin writes:
>
>> A multi-thread compress method parameter is added to hold the method we
>> are going to use. By default the 'zlib' method is used to maintain the
>> compatibility
Hi, Philippe,
On Tue, Nov 24, 2020 at 5:54 AM Philippe Mathieu-Daudé wrote:
>
> Hi Huacai,
>
> On 11/6/20 5:21 AM, Huacai Chen wrote:
> > Add Loongson-3 based machine support, it use liointc as the interrupt
> > controler and use GPEX as the pci controller. Currently it can work with
> > both
On 2020/11/27 17:48, Markus Armbruster wrote:
> Kevin, Max, suggest to skip right to Qcow2CompressionType.
>
> Zeyu Jin writes:
>
>> A multi-thread compress method parameter is added to hold the method we
>> are going to use. By default the 'zlib' method is used to maintain the
>> compatibility
Hi, Philippe,
On Tue, Nov 24, 2020 at 6:24 AM Philippe Mathieu-Daudé wrote:
>
> On 11/23/20 9:52 PM, Philippe Mathieu-Daudé wrote:
> > On 11/6/20 5:21 AM, Huacai Chen wrote:
> >> As suggested by Philippe Mathieu-Daudé, rework Loongson's liointc:
> >> 1, Move macro definitions to
Hi, Philippe,
On Tue, Nov 24, 2020 at 4:52 AM Philippe Mathieu-Daudé wrote:
>
> On 11/6/20 5:21 AM, Huacai Chen wrote:
> > As suggested by Philippe Mathieu-Daudé, rework Loongson's liointc:
> > 1, Move macro definitions to loongson_liointc.h;
> > 2, Remove magic values and use macros instead;
>
On 11/28/20 3:13 AM, Peter Maydell wrote:
> The nios2 code uses an old style of interrupt handling, where a separate
> standalone set of qemu_irqs invoke a function
> nios2_pic_cpu_handler() which signals the interrupt to the CPU proper by
> directly calling cpu_interrupt() and
On 2020-11-27 7:19 a.m., Laszlo Ersek wrote:
On 11/27/20 05:10, Ankur Arora wrote:
Yeah I was wondering what would happen for simultaneous hot add and remove.
I guess we would always do remove first and then the add, unless we hit
the break due to max_cpus_per_pass and switch to hot-add mode.
On 2020-11-27 3:47 a.m., Igor Mammedov wrote:
On Thu, 26 Nov 2020 20:10:59 -0800
Ankur Arora wrote:
On 2020-11-26 12:38 p.m., Igor Mammedov wrote:
On Thu, 26 Nov 2020 12:17:27 +0100
Laszlo Ersek wrote:
On 11/24/20 13:25, Igor Mammedov wrote:
If firmware negotiates
On 2020-11-27 7:02 a.m., Laszlo Ersek wrote:
On 11/27/20 12:33, Igor Mammedov wrote:
On Thu, 26 Nov 2020 19:35:30 -0800
Ankur Arora wrote:
On 2020-11-26 4:46 a.m., Laszlo Ersek wrote:
On 11/26/20 11:24, Ankur Arora wrote:
On 2020-11-24 4:25 a.m., Igor Mammedov wrote:
If firmware
Hi all,
+Peter Collingbourne
I'm a developer on the Android Emulator, which is in a fork of QEMU.
Peter and I have been working on an HVF Apple Silicon backend with an eye
toward Android guests.
We have gotten things to basically switch to Android userspace already
(logcat/shell and graphics
Hi Philippe, Thomas,
Op vr 27 nov. 2020 18:57 schreef Philippe Mathieu-Daudé :
> On 11/27/20 6:47 PM, Thomas Huth wrote:
> > On 27/11/2020 18.41, Philippe Mathieu-Daudé wrote:
> >> We lately realized that the Avocado framework was not designed
> >> to be regularly run on CI environments.
The openrisc code uses an old style of interrupt handling, where a
separate standalone set of qemu_irqs invoke a function
openrisc_pic_cpu_handler() which signals the interrupt to the CPU
proper by directly calling cpu_interrupt() and cpu_reset_interrupt().
Because CPU objects now inherit
We're about to refactor the OpenRISC pic_cpu code in a way that means
that just grabbing the whole qemu_irq[] array of inbound IRQs for a
CPU won't be possible any more. Abstract out a function for "return
the qemu_irq for IRQ x input of CPU y" so we can more easily replace
the implementation.
The openrisc code uses an old style of interrupt handling, where a
separate standalone set of qemu_irqs invoke a function
openrisc_pic_cpu_handler() which signals the interrupt to the CPU
proper by directly calling cpu_interrupt() and cpu_reset_interrupt().
Because CPU objects now inherit
openrisc_sim_net_init() attempts to connect the IRQ line from the
ethernet device to both CPUs in an SMP configuration by simply caling
sysbus_connect_irq() for it twice. This doesn't work, because the
second connection simply overrides the first.
Fix this by creating a TYPE_SPLIT_IRQ to split
On Thu, Nov 26, 2020 at 06:17:34PM +0300, Andrey Gruzdev wrote:
> Since reading UFFD events and saving paged data are performed
> from the same thread, write fault latencies are sensitive to
> migration stream stalls. Limiting total page saving rate is a
> method to reduce amount of noticiable
On Thu, Nov 26, 2020 at 06:17:33PM +0300, Andrey Gruzdev wrote:
> Implementation of bg_migration- iteration/completion/finish.
>
> Signed-off-by: Andrey Gruzdev
Both patch 4 & 5 look good to me in general. Maybe you can even squash this
patch into 4? It's not scarily hugeas a single patch,
Hi,
Le ven. 27 nov. 2020 à 08:18, Gerd Hoffmann a écrit :
>
> Hi,
>
> > Changes v2 -> v3 (after review of Gerd Hoffmann):
> > - Replace include on by
> >"standard-headers/linux/input.h" to try to fix build on rhel-7
>
> Now it complains about ioctl() not being declared.
>
> /me suggests
On Thu, Nov 26, 2020 at 06:17:28PM +0300, Andrey Gruzdev wrote:
> Changes v3->v4:
>
> * 1. Renamed migrate capability 'track-writes-ram'->'background-snapshot'.
> * 2. Use array of incompatible caps to replace bulky 'if' constructs.
> * 3. Moved UFFD low-level code to the separate module
On 27.11.20 21:00, Roman Bolshakov wrote:
On Thu, Nov 26, 2020 at 10:50:11PM +0100, Alexander Graf wrote:
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
On 27.11.20 20:44, Roman Bolshakov wrote:
On Thu, Nov 26, 2020 at 10:50:10PM +0100, Alexander Graf wrote:
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
On Thu, Nov 26, 2020 at 06:17:31PM +0300, Andrey Gruzdev wrote:
> In this particular implementation the same single migration
> thread is responsible for both normal linear dirty page
> migration and procesing UFFD page fault events.
>
> Processing write faults includes reading UFFD file
Il ven 27 nov 2020, 20:44 Roman Bolshakov ha
scritto:
> On Thu, Nov 26, 2020 at 10:50:10PM +0100, Alexander Graf wrote:
> > 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
On Thu, Nov 26, 2020 at 06:17:30PM +0300, Andrey Gruzdev wrote:
> Implemented support for the whole RAM block memory
> protection/un-protection. Introduced higher level
> ram_write_tracking_start() and ram_write_tracking_stop()
> to start/stop tracking guest memory writes.
The whole patch looks
On Fri, Nov 27, 2020 at 08:47:00PM +0100, Claudio Fontana wrote:
> On 11/27/20 8:04 PM, Eduardo Habkost wrote:
[...]
> > Maybe we should rename CPUClass.synchronize_from_tb to
> > CPUClass.tcg_synchronize_from_tb? Maybe we should have a
>
> possibly, yes.
>
> > separate TCGCpuOperations struct
On Fri, Nov 27, 2020 at 8:04 PM Catangiu, Adrian Costin
wrote:
> On 27/11/2020 20:22, Jann Horn wrote:
> > On Fri, Nov 20, 2020 at 11:29 PM Jann Horn wrote:
> >> On Mon, Nov 16, 2020 at 4:35 PM Catangiu, Adrian Costin
> >> wrote:
> >>> This patch is a driver that exposes a monotonic incremental
On Thu, Nov 26, 2020 at 10:50:11PM +0100, Alexander Graf wrote:
> 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
On Thu, Nov 26, 2020 at 06:17:29PM +0300, Andrey Gruzdev wrote:
> Signed-off-by: Andrey Gruzdev
The patch looks good to me, but again, any commit message would be more than
welcomed... as long as it's not empty. :)
--
Peter Xu
Hi Eduardo,
On 11/27/20 8:04 PM, Eduardo Habkost wrote:
> Now that I understand what you are doing here, I have specific
> questions about the functions you are moving, below:
>
> On Thu, Nov 26, 2020 at 11:32:14PM +0100, Claudio Fontana wrote:
>> Signed-off-by: Claudio Fontana
> [...]
>> @@
On Thu, Nov 26, 2020 at 10:50:10PM +0100, Alexander Graf wrote:
> 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
On 11/27/20 8:12 PM, Peter Maydell wrote:
> The nios2 code uses an old style of interrupt handling, where a
> separate standalone set of qemu_irqs invoke a function
> nios2_pic_cpu_handler() which signals the interrupt to the CPU proper
> by directly calling cpu_interrupt() and
Hi Phil,
On 11/27/20 2:41 PM, Philippe Mathieu-Daudé wrote:
We lately realized that the Avocado framework was not designed
to be regularly run on CI environments. Therefore, as of 5.2
we deprecate the gitlab-ci jobs using Avocado. To not disrupt
current users, it is possible to keep the current
On 11/27/20 8:12 PM, Peter Maydell wrote:
> The function nios2_check_interrupts)() looks only at CPU-internal
> state; it belongs in target/nios2, not hw/nios2. Move it into the
> same file as its only caller, so it can just be local to that file.
>
> This removes the only remaining code from
(As well as the listed nios2 maintainers, I've cc'd a couple
of the more recent contributors to this target in case they're
interested or wish to test the changes.)
The nios2 code uses an old style of interrupt handling, where a
separate standalone set of qemu_irqs invoke a function
Sorry Jann for missing your original email.
On 27/11/2020 20:22, Jann Horn wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> [resend in the hope that amazon
On Fri, 27 Nov 2020 at 19:12, Enrico Weigelt, metux IT consult
wrote:
> Several stable distros are still on python-3.5, so qemu cannot be
> built there, w/o backporting the whole python stack. In order to
> make qemu build there, make it running w/ python-3.5. The changes
> are mostly removing
The function nios2_check_interrupts)() looks only at CPU-internal
state; it belongs in target/nios2, not hw/nios2. Move it into the
same file as its only caller, so it can just be local to that file.
This removes the only remaining code from cpu_pic.c, so we can delete
that file entirely.
The nios2 code uses an old style of interrupt handling, where a
separate standalone set of qemu_irqs invoke a function
nios2_pic_cpu_handler() which signals the interrupt to the CPU proper
by directly calling cpu_interrupt() and cpu_reset_interrupt().
Because CPU objects now inherit (indirectly)
Older kernel headers lack the USBDEVFS_GET_SPEED ioctl. Qemu can easily
work without it, but the api version check isn't sufficient. Instead
time consuming bisection, for finding the really correct version, just
change the ifdef to look for the symbol, instead of api version.
Signed-off-by:
Add support for config option titles, like the real kconfig does.
Even though they're not presented anywhere yet (since minikconf
only acts in the background), it's good to have them supported,
so we can start adding descriptions in the Kconfig files.
Signed-off-by: Enrico Weigelt, metux IT
Several stable distros are still on python-3.5, so qemu cannot be
built there, w/o backporting the whole python stack. In order to
make qemu build there, make it running w/ python-3.5. The changes
are mostly removing the new type annotations (which, IMHO, just
serve for documentation purpose) and
Now that I understand what you are doing here, I have specific
questions about the functions you are moving, below:
On Thu, Nov 26, 2020 at 11:32:14PM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
[...]
> @@ -1495,7 +1497,8 @@ static inline uint64_t
Introduce virtio-gpio protocol headers from Linux kernel.
(work in progress, not mainlined yet)
Signed-off-by: Enrico Weigelt, metux IT consult
---
include/standard-headers/linux/virtio_gpio.h | 39
include/standard-headers/linux/virtio_ids.h | 1 +
2 files
Adding a driver for virtio-based GPIOs. The driver connects to
specified gpio backend and routes all requests there.
Signed-off-by: Enrico Weigelt, metux IT consult
---
MAINTAINERS | 7 +
hw/virtio/Kconfig | 7 +
hw/virtio/meson.build | 1 +
hw/virtio/virtio-gpio.c |
Some entries for autogenerated files have been missing in .gitignore.
Signed-off-by: Enrico Weigelt, metux IT consult
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b32bca1315..48ec051c2e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,5
Add support for config option titles, like the real kconfig does.
Even though they're not presented anywhere yet (since minikconf
only acts in the background), it's good to have them supported,
so we can start adding descriptions in the Kconfig files.
Signed-off-by: Enrico Weigelt, metux IT
Introducing a backend subsys for hardware GPIOs, so we can now
let simulated GPIO devices actually do something, by talking to
pluggable GPIO backends (eg. speaking to host's gpio subsystem,
gpiod, custom simulation, etc).
This patch does not implement any actual gpio backend, nor any
any any hw
Adding a dummy GPIO backend driver. Essentially stores the states
in memory and gives some debug output. The current state can be
accessed as a string property.
Signed-off-by: Enrico Weigelt, metux IT consult
---
MAINTAINERS | 1 +
backends/Kconfig| 5 ++
On Fri, 27 Nov 2020 at 17:08, wrote:
>
> From: Marc-André Lureau
>
> The following changes since commit ea8208249d1082eae0444934efb3b59cd3183f05:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/fixes-20201127-pull-request' into staging (2020-11-27
> 11:11:43
On 11/27/20 7:29 PM, Thomas Huth wrote:
> On 27/11/2020 18.57, Philippe Mathieu-Daudé wrote:
>> On 11/27/20 6:47 PM, Thomas Huth wrote:
>>> On 27/11/2020 18.41, Philippe Mathieu-Daudé wrote:
We lately realized that the Avocado framework was not designed
to be regularly run on CI
On Fri, Nov 27, 2020 at 07:16:25PM +0100, Claudio Fontana wrote:
> On 11/27/20 7:09 PM, Eduardo Habkost wrote:
> > On Fri, Nov 27, 2020 at 06:53:23PM +0100, Claudio Fontana wrote:
> >> On 11/27/20 6:41 PM, Eduardo Habkost wrote:
> >>> On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana
On Fri, Nov 27, 2020 at 07:15:43PM +0100, Thomas Huth wrote:
> On 27/11/2020 19.10, Thomas Huth wrote:
> > After adding some missing packages, it's possible to check 32-bit
> > builds and tests with the fedora-i386-cross container in the gitlab-CI,
> > too.
> >
> > While we're at it, update it to
On 27/11/2020 18.57, Philippe Mathieu-Daudé wrote:
> On 11/27/20 6:47 PM, Thomas Huth wrote:
>> On 27/11/2020 18.41, Philippe Mathieu-Daudé wrote:
>>> We lately realized that the Avocado framework was not designed
>>> to be regularly run on CI environments. Therefore, as of 5.2
>>> we deprecate
- Background
The VM Generation ID is a feature defined by Microsoft (paper:
http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
multiple hypervisor vendors.
The feature is required in virtualized environments by apps that work
with local copies/caches of world-unique data such as
On 27/11/20 19:15, Thomas Huth wrote:
On 27/11/2020 19.10, Thomas Huth wrote:
After adding some missing packages, it's possible to check 32-bit
builds and tests with the fedora-i386-cross container in the gitlab-CI,
too.
While we're at it, update it to Fedora 31. Unfortunately the gcc
from the
[resend in the hope that amazon will accept my mail this time instead
of replying "550 Too many invalid recipients" again]
On Fri, Nov 20, 2020 at 11:29 PM Jann Horn wrote:
> On Mon, Nov 16, 2020 at 4:35 PM Catangiu, Adrian Costin
> wrote:
> > This patch is a driver that exposes a monotonic
On Fri, Nov 27, 2020 at 06:16:27PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 17:18, Eduardo Habkost wrote:
> > Thanks! Is the data returned by kvm_arm_get_host_cpu_features()
> > supposed to eventually affect the value of id_aa64mmfr0? I don't
> > see how that could happen.
>
>
On 11/27/20 7:13 PM, Eduardo Habkost wrote:
> On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
>> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
>>> On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
add a new optional interface to CPUClass,
which allows
On Fri, 27 Nov 2020 at 17:18, Eduardo Habkost wrote:
> Thanks! Is the data returned by kvm_arm_get_host_cpu_features()
> supposed to eventually affect the value of id_aa64mmfr0? I don't
> see how that could happen.
kvm_arm_get_host_cpu_features() does:
err |= read_sys_reg64(fdarray[2],
On 11/27/20 7:09 PM, Eduardo Habkost wrote:
> On Fri, Nov 27, 2020 at 06:53:23PM +0100, Claudio Fontana wrote:
>> On 11/27/20 6:41 PM, Eduardo Habkost wrote:
>>> On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
i386 is the first user of AccelCPUClass, allowing to split
On 27/11/2020 19.10, Thomas Huth wrote:
> After adding some missing packages, it's possible to check 32-bit
> builds and tests with the fedora-i386-cross container in the gitlab-CI,
> too.
>
> While we're at it, update it to Fedora 31. Unfortunately the gcc
> from the later versions emits some
On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> >> add a new optional interface to CPUClass,
> >> which allows accelerators to extend the CPUClass
> >> with
After adding some missing packages, it's possible to check 32-bit
builds and tests with the fedora-i386-cross container in the gitlab-CI,
too.
While we're at it, update it to Fedora 31. Unfortunately the gcc
from the later versions emits some very dubious format-truncation
warnings, so Fedora 32
On Fri, Nov 27, 2020 at 06:53:23PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:41 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
> >> i386 is the first user of AccelCPUClass, allowing to split
> >> cpu.c into:
> >>
> >> cpu.ccpuid and
On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
>> add a new optional interface to CPUClass,
>> which allows accelerators to extend the CPUClass
>> with additional accelerator-specific initializations.
>>
>> Signed-off-by: Claudio
On 11/27/20 6:47 PM, Thomas Huth wrote:
> On 27/11/2020 18.41, Philippe Mathieu-Daudé wrote:
>> We lately realized that the Avocado framework was not designed
>> to be regularly run on CI environments. Therefore, as of 5.2
>> we deprecate the gitlab-ci jobs using Avocado. To not disrupt
>> current
On 11/27/20 6:41 PM, Eduardo Habkost wrote:
> On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
>> i386 is the first user of AccelCPUClass, allowing to split
>> cpu.c into:
>>
>> cpu.ccpuid and common x86 cpu functionality
>> host-cpu.c host x86 cpu functions and
On 11/26/20 11:10 PM, Eduardo Habkost wrote:
> On Thu, Nov 26, 2020 at 10:50:09PM +0100, Alexander Graf wrote:
>> 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
On 27/11/2020 18.41, Philippe Mathieu-Daudé wrote:
> We lately realized that the Avocado framework was not designed
> to be regularly run on CI environments. Therefore, as of 5.2
> we deprecate the gitlab-ci jobs using Avocado. To not disrupt
> current users, it is possible to keep the current
On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
> i386 is the first user of AccelCPUClass, allowing to split
> cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c host x86 cpu functions and "host" cpu type
> kvm/cpu.cKVM x86
We lately realized that the Avocado framework was not designed
to be regularly run on CI environments. Therefore, as of 5.2
we deprecate the gitlab-ci jobs using Avocado. To not disrupt
current users, it is possible to keep the current behavior by
setting the
On 27.11.2020 18:45, Peter Xu wrote:
On Fri, Nov 27, 2020 at 01:00:48PM +0300, Andrey Gruzdev wrote:
On 27.11.2020 12:49, Peter Krempa wrote:
On Fri, Nov 27, 2020 at 11:21:39 +0300, Andrey Gruzdev wrote:
On 26.11.2020 18:47, Peter Krempa wrote:
On Thu, Nov 26, 2020 at 18:17:28 +0300, Andrey
On 18/11/2020 12:30, Alexander Graf wrote:
>
>
> On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
>> - Future improvements
>>
>> Ideally we would want the driver to register itself based on devices'
>> _CID and not _HID, but unfortunately I couldn't find a way to do that.
>> The problem is that
On Fri, Nov 27, 2020 at 04:53:59PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 16:47, Eduardo Habkost wrote:
> > Do you know how the implicitly-accelerator-specific code is
> > implemented? PARange is in id_aa64mmfr0, correct? I don't see
> > any accel-specific code for initializing
From: Marc-André Lureau
An out-of-bounds access issue was found in the SLIRP user networking
implementation of QEMU. It could occur while processing ARP/NCSI
packets, if the packet length was shorter than required to accommodate
respective protocol headers and payload. A privileged guest user
From: Marc-André Lureau
The following changes since commit ea8208249d1082eae0444934efb3b59cd3183f05:
Merge remote-tracking branch
'remotes/kraxel/tags/fixes-20201127-pull-request' into staging (2020-11-27
11:11:43 +)
are available in the Git repository at:
g...@github.com:elmarco
On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> add a new optional interface to CPUClass,
> which allows accelerators to extend the CPUClass
> with additional accelerator-specific initializations.
>
> Signed-off-by: Claudio Fontana
> ---
[...]
> +static void
On Fri, 27 Nov 2020 14:00:16 -0300
Wainer dos Santos Moschetta wrote:
> Hi,
>
> On 11/26/20 10:01 AM, Cornelia Huck wrote:
> > This adds a very basic test for checking that we present devices
> > in a way that Linux can consume: boot with both virtio-net-ccw and
> > virtio-net-pci attached and
Hi,
On 11/26/20 10:01 AM, Cornelia Huck wrote:
This adds a very basic test for checking that we present devices
in a way that Linux can consume: boot with both virtio-net-ccw and
virtio-net-pci attached and then verify that Linux is able to see
and detect these devices.
Signed-off-by: Cornelia
On Fri, 27 Nov 2020 at 16:47, Eduardo Habkost wrote:
> Do you know how the implicitly-accelerator-specific code is
> implemented? PARange is in id_aa64mmfr0, correct? I don't see
> any accel-specific code for initializing id_aa64mmfr0.
For TCG, the value of id_aa64mmfr0 is set by the per-cpu
On Thu, 26 Nov 2020 14:01:58 +0100
Cornelia Huck wrote:
> This adds a very basic test for checking that we present devices
> in a way that Linux can consume: boot with both virtio-net-ccw and
> virtio-net-pci attached and then verify that Linux is able to see
> and detect these devices.
>
>
On 11/27/20 16:07, Igor Mammedov wrote:
> On Fri, 27 Nov 2020 15:48:34 +0100
> Laszlo Ersek wrote:
>> The firmware logic needs to be aware of is_removing though, at least
>> understand the existence of this bit, as the "get pending" command
>> will report such CPUs too that only have is_removing
Kevin Wolf writes:
> Am 27.11.2020 um 13:21 hat Markus Armbruster geschrieben:
>> >> I fell down this (thankfully shallow) rabbit hole because we also have
>> >>
>> >> { 'enum': 'MultiFDCompression',
>> >> 'data': [ 'none', 'zlib',
>> >> { 'name': 'zstd', 'if':
Claudio Fontana writes:
> On 11/27/20 3:45 PM, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>>> On 11/26/20 10:48 PM, Eduardo Habkost wrote:
On Thu, Nov 26, 2020 at 10:06:03PM +0100, Claudio Fontana wrote:
> On 11/26/20 3:25 PM, Paolo Bonzini wrote:
>> On 26/11/20 15:13,
On Fri, 27 Nov 2020 at 16:38, Peter Maydell wrote:
> Having looked a bit more closely at some of the relevant target/arm
> code, I think the best approach is going to be that in virt.c
> we just check the PARange ID register field (probably via
> a convenience function that does the conversion of
On Fri, Nov 27, 2020 at 04:38:18PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 16:26, Eduardo Habkost wrote:
> >
> > On Thu, Nov 26, 2020 at 10:29:01PM +, Peter Maydell wrote:
> > > On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote:
> > > > Direct checks for *_enabled() are a pain
On Fri, 27 Nov 2020 at 16:26, Eduardo Habkost wrote:
>
> On Thu, Nov 26, 2020 at 10:29:01PM +, Peter Maydell wrote:
> > On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote:
> > > Direct checks for *_enabled() are a pain to clean up later when
> > > we add support to new accelerators. Can't
On Fri, Nov 27, 2020 at 15:53:16 +, Daniel Berrange wrote:
> On Fri, Nov 27, 2020 at 01:18:09PM +0100, Peter Krempa wrote:
> > On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote:
[...]
> IIUC, this all relies on us importing a dump of the latest QEMU
> capabilities into the
On Fri, Nov 27, 2020 at 16:44:05 +0100, Markus Armbruster wrote:
> Peter Krempa writes:
>
> > On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote:
> >> On Fri, Nov 27, 2020 at 12:21:54PM +0100, Peter Krempa wrote:
[...]
> > As you can see this has an issue when we have to add
On Thu, Nov 26, 2020 at 10:29:01PM +, Peter Maydell wrote:
> On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote:
> >
> > On Thu, Nov 26, 2020 at 10:50:17PM +0100, Alexander Graf wrote:
> > > The Apple M1 only supports up to 36 bits of physical address space. That
> > > means we can not fit
On Fri, Nov 27, 2020 at 01:18:09PM +0100, Peter Krempa wrote:
> On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote:
> > On Fri, Nov 27, 2020 at 12:21:54PM +0100, Peter Krempa wrote:
> > > On Fri, Nov 27, 2020 at 10:50:59 +, Daniel Berrange wrote:
> > > > Copying libvir-list for the
Hi,
QEMU Advent Calendar 2020 is around the corner and we are looking for
volunteers to contribute disk images that showcase something cool, bring
back retro computing memories, or simply entertain with a puzzle or game.
QEMU Advent Calendar publishes a QEMU disk image each day from
December
On Fri, Nov 27, 2020 at 01:00:48PM +0300, Andrey Gruzdev wrote:
> On 27.11.2020 12:49, Peter Krempa wrote:
> > On Fri, Nov 27, 2020 at 11:21:39 +0300, Andrey Gruzdev wrote:
> > > On 26.11.2020 18:47, Peter Krempa wrote:
> > > > On Thu, Nov 26, 2020 at 18:17:28 +0300, Andrey Gruzdev via wrote:
> >
Ensure no packet bigger then NET_BUFSIZE is queued via
qemu_net_queue_append*() by adding assertions.
Signed-off-by: Philippe Mathieu-Daudé
---
net/queue.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/queue.c b/net/queue.c
index 221a1c87961..94b98b19ef9 100644
--- a/net/queue.c
On 11/27/20 4:45 PM, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This is a simple attempt to avoid the following pattern:
>
> ssize_t pkt_size = get_pkt_size(); // returns errno
Sorry, I meant: returns "-errno" (< 0).
>
> // no check
>
> send_packet(size_t size=pkt_size); // size casted to
Do not allow qemu_send_packet*() and qemu_net_queue_send()
functions to accept packets bigger then NET_BUFSIZE.
Signed-off-by: Philippe Mathieu-Daudé
---
We have to put a limit somewhere. NET_BUFSIZE is defined as:
/* Maximum GSO packet size (64k) plus plenty of room for
* the ethernet and
On Fri, Nov 20, 2020 at 07:50:38PM +0100, Eugenio Pérez wrote:
This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay on vDPA device's dirty logging capability, SW assisted LM
intercepts dataplane,
Hi,
This is a simple attempt to avoid the following pattern:
ssize_t pkt_size = get_pkt_size(); // returns errno
// no check
send_packet(size_t size=pkt_size); // size casted to unsigned
// -> overflow
Regards,
Phil.
Philippe Mathieu-Daudé (2):
Peter Krempa writes:
> On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote:
>> On Fri, Nov 27, 2020 at 12:21:54PM +0100, Peter Krempa wrote:
>> > On Fri, Nov 27, 2020 at 10:50:59 +, Daniel Berrange wrote:
>> > > Copying libvir-list for the deprecation warning.
>> > >
>> > >
>> >
1 - 100 of 232 matches
Mail list logo
