On Tue, 8 Jul 2025 at 20:07, Peter Maydell wrote:
>
> On Fri, 4 Jul 2025 at 23:32, Jackson Donaldson wrote:
> >
> > v4:
> >
> > Spacing and style standard changes in GCR SOC, TRNG SOC, and AES SOC
> >
>
> I've applied this version to target-arm.next; I expect to get this
> into the 10.1 release.
This series introduces support for passt as a new network backend for
QEMU.
The purpose of this new backend is to help to use passt daemon as
easily as the user backend ('-nic passt' as we have '-nic user').
All the passt functionalities will not be available to keep it simple,
and the goal is not
On Fri, 4 Jul 2025 at 23:32, Jackson Donaldson wrote:
>
> v4:
>
> Spacing and style standard changes in GCR SOC, TRNG SOC, and AES SOC
>
I've applied this version to target-arm.next; I expect to get this
into the 10.1 release. Thanks!
-- PMM
v4:
Spacing and style standard changes in GCR SOC, TRNG SOC, and AES SOC
v3:
Addresses a few more comments by Peter. Really appreciate the review, thank you.
ICC SOC:
Gave each device a unique name
UART SOC:
Removed references to DeviceState and gave each device a unique name
GCR SOC:
Set obj
This really made my day :-) Thanks Peter!
Best regards,
William
On Fri, Jul 4, 2025 at 22:29 Peter Maydell wrote:
> On Thu, 3 Jul 2025 at 09:56, William Kosasih
> wrote:
> >
> > Historically, M-profile helper functions in m_helper.c and mve_helper.c
> > used the unaligned cpu_*_data_ra() routi
On Thu, 3 Jul 2025 at 09:56, William Kosasih wrote:
>
> Historically, M-profile helper functions in m_helper.c and mve_helper.c
> used the unaligned cpu_*_data_ra() routines to perform guest memory
> accesses. This meant we had no way to enforce alignment constraints
> when executing helper-based
Hi,
ntroduce the advanced extended interrupt controllers (AVECINTC). This
feature will allow each core to have 256 independent interrupt vectors
and MSI interrupts can be independently routed to any vector on any CPU.
The whole topology of irqchips in LoongArch machines looks like this if
AVECINT
Historically, M-profile helper functions in m_helper.c and mve_helper.c
used the unaligned cpu_*_data_ra() routines to perform guest memory
accesses. This meant we had no way to enforce alignment constraints
when executing helper-based loads/stores. With the addition of the
cpu_*_mmu() APIs, we can
In v4 I am addressing review comments.
Djordje Todorovic (11):
hw/intc: Allow gaps in hartids for aclint and aplic
target/riscv: Add cpu_set_exception_base
target/riscv: Add MIPS P8700 CPU
target/riscv: Add MIPS P8700 CSRs
target/riscv: Add mips.ccmov instruction
target/riscv: Add mips
On 2025/05/27 22:46, Peter Xu wrote:
On Tue, May 27, 2025 at 11:09:08AM +0900, Akihiko Odaki wrote:
On 2025/05/26 23:48, Peter Xu wrote:
On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
Akihiko Odaki (11):
futex: Check value after qemu_futex_wait()
futex: Support
On 2025/05/28 0:01, Paolo Bonzini wrote:
On Tue, May 27, 2025 at 5:01 AM Akihiko Odaki wrote:
I'd like to submit it with "[PATCH v4 05/11] qemu-thread: Avoid futex
abstraction for non-Linux" because it aligns the implementations of
Linux and non-Linux versions to rely on a store-release of EV_S
On Tue, May 27, 2025 at 5:01 AM Akihiko Odaki wrote:
> I'd like to submit it with "[PATCH v4 05/11] qemu-thread: Avoid futex
> abstraction for non-Linux" because it aligns the implementations of
> Linux and non-Linux versions to rely on a store-release of EV_SET in
> qemu_event_set().
Ok, I see w
On Tue, May 27, 2025 at 11:09:08AM +0900, Akihiko Odaki wrote:
> On 2025/05/26 23:48, Peter Xu wrote:
> > On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
> > > Akihiko Odaki (11):
> > >futex: Check value after qemu_futex_wait()
> > >futex: Support Windows
> > >
On 2025/05/27 1:51, Paolo Bonzini wrote:
On 5/26/25 07:29, Akihiko Odaki wrote:
Changes in v4:
- Added patch "qemu-thread: Remove qatomic_read() in qemu_event_set()".
Hi Akihiko,
I'm not so confident about putting this patch before the other changes;
I'm referring basically to this hunk:
dif
On 2025/05/26 23:48, Peter Xu wrote:
On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
Akihiko Odaki (11):
futex: Check value after qemu_futex_wait()
futex: Support Windows
qemu-thread: Remove qatomic_read() in qemu_event_set()
qemu-thread: Replace __linu
On 5/26/25 07:29, Akihiko Odaki wrote:
Changes in v4:
- Added patch "qemu-thread: Remove qatomic_read() in qemu_event_set()".
Hi Akihiko,
I'm not so confident about putting this patch before the other changes;
I'm referring basically to this hunk:
diff --git a/util/event.c b/util/event.c
inde
On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
> Akihiko Odaki (11):
> futex: Check value after qemu_futex_wait()
> futex: Support Windows
> qemu-thread: Remove qatomic_read() in qemu_event_set()
> qemu-thread: Replace __linux__ with CONFIG_LINUX
> qemu
In a recent discussion, Phil Dennis-Jordan pointed out a quirk in
QemuEvent destruction due to futex-like abstraction, which prevented
the usage of QemuEvent in new and existing code[1]. With some more
thoughts after this discussion, I also found other problem and room
of improvement in futex usage
This patchset addresses four bugs related to AMD PMU virtualization.
1. The PerfMonV2 is still available if PERCORE if disabled via
"-cpu host,-perfctr-core".
2. The VM 'cpuid' command still returns PERFCORE although "-pmu" is
configured.
3. The third issue is that using "-cpu host,-pmu" does no
On Fri, Mar 07, 2025 at 12:25:32PM +0100, Victor Toso wrote:
> Hi,
>
> On Mon, Feb 17, 2025 at 05:52:49PM +0100, Victor Toso wrote:
> > On Mon, Feb 17, 2025 at 02:58:22PM +, Daniel P. Berrangé wrote:
> > > On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> > > >
>
Hi,
On Mon, Feb 17, 2025 at 05:52:49PM +0100, Victor Toso wrote:
> On Mon, Feb 17, 2025 at 02:58:22PM +, Daniel P. Berrangé wrote:
> > On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> > >
> > > # Expectations #
> > >
> > >
> > > As is, this stil
Daniel P. Berrangé writes:
[...]
> When I think about the code generator and how this will all
> evolve over time, I have a strong feeling that none of this
> should be in qemu.git.
Yes, keeping it in qemu.git has its drawbacks. Testing is awkward
there. The coupling could cause friction.
I'
Hi,
On Mon, Feb 17, 2025 at 02:58:22PM +, Daniel P. Berrangé wrote:
> On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> > Hi again,
> >
> > This patch series intent is to introduce a generator that produces a Go
> > module for Go applications to interact over QMP with QEMU.
> >
On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> Hi again,
>
> This patch series intent is to introduce a generator that produces a Go
> module for Go applications to interact over QMP with QEMU.
>
> Previous version (10 Jan 2025)
> https://lists.gnu.org/archive/html/qemu-devel/
On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> Hi again,
>
> This patch series intent is to introduce a generator that produces a Go
> module for Go applications to interact over QMP with QEMU.
>
> Previous version (10 Jan 2025)
> https://lists.gnu.org/archive/html/qemu-devel/
Hi again,
This patch series intent is to introduce a generator that produces a Go
module for Go applications to interact over QMP with QEMU.
Previous version (10 Jan 2025)
https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg01530.html
The generated code was mostly tested using existing
On Thu, Jan 9, 2025 at 6:10 PM Alistair Francis wrote:
>
> On Wed, Dec 4, 2024 at 9:18 AM Atish Patra wrote:
> >
> > This series adds the counter delegation extension support. The counter
> > delegation ISA extension(Smcdeleg/Ssccfg) actually depends on multiple ISA
> > extensions.
> >
> > 1. S[m
On Wed, Dec 4, 2024 at 9:18 AM Atish Patra wrote:
>
> This series adds the counter delegation extension support. The counter
> delegation ISA extension(Smcdeleg/Ssccfg) actually depends on multiple ISA
> extensions.
>
> 1. S[m|s]csrind : The indirect CSR extension[1] which defines additional
>
This series adds the counter delegation extension support. The counter
delegation ISA extension(Smcdeleg/Ssccfg) actually depends on multiple ISA
extensions.
1. S[m|s]csrind : The indirect CSR extension[1] which defines additional
5 ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitat
From: Michael Kowal
These changes provide enhanced support of the External Interrupt Virtualization
Engine. The changes are focused on the following areas:
- Cache Watch, Cache Flush and Sync Injection
- Virtual Structure Tables
- Set Translation Table
- 'info pic' command data that is dumpe
On Tue, Jul 9, 2024 at 9:41 PM LIU Zhiwei wrote:
>
> I once used a wrong major opcode for zimop. It should use 0x73 as major
> opcode.
> This was detected after I got a toolchain with zimop support. Before that, I
> tested
> this implementation with hardwire code instruction instead of assemble
I once used a wrong major opcode for zimop. It should use 0x73 as major opcode.
This was detected after I got a toolchain with zimop support. Before that, I
tested
this implementation with hardwire code instruction instead of assemble code.
This patch set has been queued to alistair/riscv-to-appl
Overview
Add support for Power11 pseries and powernv machine types, to emulate VMs
running on Power11.
As Power11 core is same as Power10, hence much of the code has been reused from
Power10.
Power11 was added in Linux in:
commit c2ed087ed35c ("powerpc: Add Power11 architected and
Am 8. Januar 2024 22:12:12 UTC schrieb Mark Cave-Ayland
:
>On 08/01/2024 20:07, Bernhard Beschow wrote:
>
>> Am 7. Januar 2024 14:13:44 UTC schrieb Mark Cave-Ayland
>> :
>>> On 06/01/2024 21:05, Bernhard Beschow wrote:
>>>
This series implements relocation of the SuperI/O functions of th
On 08/01/2024 20:07, Bernhard Beschow wrote:
Am 7. Januar 2024 14:13:44 UTC schrieb Mark Cave-Ayland
:
On 06/01/2024 21:05, Bernhard Beschow wrote:
This series implements relocation of the SuperI/O functions of the VIA south
bridges which resolves some FIXME's. It is part of my via-apollo-pr
Am 7. Januar 2024 14:13:44 UTC schrieb Mark Cave-Ayland
:
>On 06/01/2024 21:05, Bernhard Beschow wrote:
>
>> This series implements relocation of the SuperI/O functions of the VIA south
>> bridges which resolves some FIXME's. It is part of my via-apollo-pro-133t
>> branch [1] which is an extens
On 06/01/2024 21:05, Bernhard Beschow wrote:
This series implements relocation of the SuperI/O functions of the VIA south
bridges which resolves some FIXME's. It is part of my via-apollo-pro-133t
branch [1] which is an extension of bringing the VIA south bridges to the PC
machine [2]. This branc
This series implements relocation of the SuperI/O functions of the VIA south
bridges which resolves some FIXME's. It is part of my via-apollo-pro-133t
branch [1] which is an extension of bringing the VIA south bridges to the PC
machine [2]. This branch is able to run some real-world X86 BIOSes in t
This series of patches includes support, tests and fixes for
adding PCA9552 and PCA9554 I2C devices to the powernv10 chip.
The PCA9552 device is used for PCIe slot hotplug power control
and monitoring, while the PCA9554 device is used for presence
detection of IBM CableCard devices. Both devices
On Wed, 18 Oct 2023 at 19:13, Nabih Estefan wrote:
>
> From: Nabih Estefan Diaz
>
> [Changes since v3]
> Fixed comments from Hao Wu (wuhao...@google.com)
>
> [Changes since v2]
> Fixed bugs related to the RC functionality of the GMAC. Added and
> squashed patches related to that.
> [Changes since
From: Nabih Estefan Diaz
[Changes since v3]
Fixed comments from Hao Wu (wuhao...@google.com)
[Changes since v2]
Fixed bugs related to the RC functionality of the GMAC. Added and
squashed patches related to that.
[Changes since v1]
Fixed some errors in formatting.
Fixed a merge error that I didn'
On 06.09.23 14:04, David Hildenbrand wrote:
If there are no more comments, I'll queue this myself soon.
Queued to
https://github.com/davidhildenbrand/qemu.git mem-next
--
Cheers,
David / dhildenb
If there are no more comments, I'll queue this myself soon.
---
This is the result of the previous discussion of:
* "[PATCH v2] softmmu/physmem: try opening file readonly before failure
in file_ram_open" [1]
* "[PATCH v1 0/3] softmmu/physmem: file_ram_open() readonly
improvements" [2]
Afte
Migration of a guest in the suspended runstate is broken. The incoming
migration code automatically tries to wake the guest, which is wrong;
the guest should end migration in the same runstate it started. Further,
for a restored snapshot, the automatic wakeup fails. The runstate is
RUNNING, but
This patch series allow qemu-system-loongarch64 to emulate a LoongArch32
machine. A new CPU model is added for loongarch32. Initial GDB support
is added.
At the same time, VA32(32-bit virtual address) support is introduced for
LoongArch64.
LA32 support is tested using a small supervisor program a
On Mon, 15 May 2023 at 21:25, Niek Linnenbank wrote:
>
> Hi Qianfan,
>
> Thanks for sending the v4. I've reviewed all patches and replied to each
> individual patch.
>
> Great work so far!
>
> One thing I wanted to mention is that when you receive a 'Reviewed-by:' or
> 'Tested-by:' line from a r
Hi Qianfan,
Thanks for sending the v4. I've reviewed all patches and replied to each
individual patch.
Great work so far!
One thing I wanted to mention is that when you receive a 'Reviewed-by:' or
'Tested-by:' line from a reviewer,
please feel free to include it in the commit message on the next
From: qianfan Zhao
*** history ***
# v1: 2023-03-21
The first version which add allwinner-r40 support, supported features:
+ ccu
+ dram controller
+ uart
+ i2c and pmic(axp221)
+ sdcard
+ emac/gmac
Also provide a test case under avocado, running quickly test:
$ AVOCADO_ALLOW_LARGE_STORAGE=y
Upstream the implementations of bind(2), connect(2), accept(2) and
getpeername(2) system calls from the blitz branch of the bsd-user fork hosted at
https://github.com/qemu-bsd-user/qemu-bsd-user/tree/blitz.
Karim Taha (1):
Signed-off-by: Karim Taha
Sean Bruno (1):
Signed-off-by: Karim Taha
From: Marc-André Lureau
Hi,
The series focuses on 'add_client' win32 support, by limiting its scope to
sockets and adding a new command to import sockets. This enables vnc-display
test on win32, exercising the new code paths.
(a follow up series will add dbus display support on win32, with test
Hi all!
Let's get rid of pattern
result = self.vm.qmp(...)
self.assert_qmp(result, 'return', {})
And switch to just
self.vm.cmd(...)
v4: resend to fix CC
v3: rebase on master, fix some over-80 lines
Vladimir Sementsov-Ogievskiy (11):
python: rename QEMUMonitorProtocol.cmd() to c
Hi,
This new version is still rebased on top of [1]:
"[PATCH 00/12] hw/riscv: Improve Spike HTIF emulation fidelity"
from Bin Meng.
In this version there's a new patch, patch 4, where we added a
g_assert() guard in both riscv_load_kernel() and riscv_load_initrd(), as
proposed by Alex in the v3
This is a dump of all minor coroutine-related fixes found while looking
around and testing various things in the QEMU block layer.
Patches aim to:
- add missing coroutine_fn annotation to the functions
- simplify to avoid the typical "if in coroutine: fn()
// else create_coroutine(fn)" already p
1)
Performance improvement
Add pkt and insn to DisasContext
Many functions need information from all 3 structures, so merge
them together.
2)
Bug fix
Fix predicated assignment to .tmp and .cur
3)
Performance improvement
Add overrides for S2_asr_r_r_sat/S2_asl_r_r_sat
These functions will not be
"-netdev socket" only supports inet sockets.
It's not a complex task to add support for unix sockets, but
the socket netdev parameters are not defined to manage well unix
socket parameters.
As discussed in:
"socket.c added support for unix domain socket datagram transport"
https://lore.kern
On 3/6/22 20:50, Bernhard Beschow wrote:
Bernhard Beschow (11):
hw/southbridge/piix: Aggregate all PIIX southbridge type names
hw/isa/piix4: Use object_initialize_child() for embedded struct
hw/isa/piix4: Move pci_map_irq_fn' near pci_set_irq_fn
hw/isa/piix4: QOM'ify PCI device creat
Based-on: <20220607204557.658541-1-richard.hender...@linaro.org>
("[PATCH v4 00/53] semihosting cleanup")
Changes for v4:
* Split out of v2.
* Undo the gdb errno thing; continue to convert between host and uhi.
r~
Richard Henderson (11):
target/mips: Use an exception for semihosting
ta
On 03/06/2022 19:50, Bernhard Beschow wrote:
v4:
* Rebase onto
https://patchew.org/QEMU/20220530112718.26582-1-philippe.mathieu.da...@gmail.com/
* Cosmetics (fix typo, omit "include") (Mark, Philippe)
* Split piix3 and piix4 (Philippe)
* s/Found-by/Reported-by/ (Philippe)
* Don't alias smbus (M
v4:
* Rebase onto
https://patchew.org/QEMU/20220530112718.26582-1-philippe.mathieu.da...@gmail.com/
* Cosmetics (fix typo, omit "include") (Mark, Philippe)
* Split piix3 and piix4 (Philippe)
* s/Found-by/Reported-by/ (Philippe)
* Don't alias smbus (Mark)
v3:
* Rebase onto 'hw/acpi/piix4: remove l
Implement Vector-Enhancements Facility 2 for s390x
resolves: https://gitlab.com/qemu-project/qemu/-/issues/738
implements:
VECTOR LOAD ELEMENTS REVERSED (VLER)
VECTOR LOAD BYTE REVERSED ELEMENTS (VLBR)
VECTOR LOAD BYTE REVERSED ELEMENT (VLEBRH, VLEBRF,
For QEMU, the majority of the work in enabling instruction interpretation
is handled via a new KVM ioctls to enable interpretation, interrupt
forwarding and registration of the guest IOAT tables. In order to make
use of the KVM-managed IOMMU domain operations on the ho
On Mon, Feb 7, 2022 at 9:47 AM Christian Schoenebeck
wrote:
> On Sonntag, 6. Februar 2022 21:07:08 CET Will Cohen wrote:
> > This is a followup to
> > https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg05993.html,
> > adding 9p server support for Darwin.
> >
> > Since v3, the following c
On Sonntag, 6. Februar 2022 21:07:08 CET Will Cohen wrote:
> This is a followup to
> https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg05993.html,
> adding 9p server support for Darwin.
>
> Since v3, the following changes have been made:
>
> - Move XATTR_SIZE_MAX to P9_XATTR_SIZE MAX in
This is a followup to
https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg05993.html,
adding 9p server support for Darwin.
Since v3, the following changes have been made:
- Move XATTR_SIZE_MAX to P9_XATTR_SIZE MAX in 9p.h, and provide explanatory
context as preliminary solution
- Add ex
The latest version of the SBI specification includes a Performance Monitoring
Unit(PMU) extension[1] which allows the supervisor to start/stop/configure
various PMU events. The Sscofpmf ('Ss' for Privileged arch and Supervisor-level
extensions, and 'cofpmf' for Count OverFlow and Privilege Mode Fil
Hi,
This series attempts to add support for Xilinx Versal's PMC SLCR
(system-level control registers) and OSPI flash memory controller to
Xilinx Versal virt machine.
The series start with adding a model of Versal's PMC SLCR and connecting
the model to the Versal virt machine. The series then adds
On 11/15/21 15:58, Philippe Mathieu-Daudé wrote:
> Missing review: patches #4 to #8 (new)
>
> Yet another approach to fix test-smp-parse. v2 from Yanan Wang:
> https://lore.kernel.org/qemu-devel/2021024429.10568-1-wangyana...@huawei.com/
>
> Here we use the QOM class_init() to avoid having t
Missing review: patches #4 to #8 (new)
Yet another approach to fix test-smp-parse. v2 from Yanan Wang:
https://lore.kernel.org/qemu-devel/2021024429.10568-1-wangyana...@huawei.com/
Here we use the QOM class_init() to avoid having to deal with
object_unref() and deinit().
Since v3:
- Restore
On Tue, Oct 19, 2021 at 04:39:20PM +0100, Jean-Philippe Brucker wrote:
> On Mon, Oct 18, 2021 at 11:25:05AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Oct 08, 2021 at 04:17:37PM +0100, Jean-Philippe Brucker wrote:
> > > On Tue, Oct 05, 2021 at 11:45:42AM -0400, Michael S. Tsirkin wrote:
> > > > L
On Mon, Oct 18, 2021 at 11:25:05AM -0400, Michael S. Tsirkin wrote:
> On Fri, Oct 08, 2021 at 04:17:37PM +0100, Jean-Philippe Brucker wrote:
> > On Tue, Oct 05, 2021 at 11:45:42AM -0400, Michael S. Tsirkin wrote:
> > > Looks like this can not be applied yet because the bypass bit
> > > isn't in yet
On Fri, Oct 08, 2021 at 04:17:37PM +0100, Jean-Philippe Brucker wrote:
> On Tue, Oct 05, 2021 at 11:45:42AM -0400, Michael S. Tsirkin wrote:
> > Looks like this can not be applied yet because the bypass bit
> > isn't in yet. what's up with that?
>
> The boot-bypass bit isn't a hard dependency for
On Tue, Oct 12, 2021 at 1:34 AM Jean-Philippe Brucker
wrote:
>
> Hi Haiwei,
>
> On Mon, Oct 11, 2021 at 06:10:07PM +0800, Haiwei Li wrote:
> [...]
> > Gave up waiting for root file system device. Common problems:
> > - Boot args (cat /proc/cmdline)
> >- Check rootdelay= (did the system wait
Hi Haiwei,
On Mon, Oct 11, 2021 at 06:10:07PM +0800, Haiwei Li wrote:
[...]
> Gave up waiting for root file system device. Common problems:
> - Boot args (cat /proc/cmdline)
>- Check rootdelay= (did the system wait long enough?)
> - Missing modules (cat /proc/modules; ls /dev)
> ALERT! UUI
On Fri, Oct 8, 2021 at 11:18 PM Jean-Philippe Brucker
wrote:
>
> On Tue, Oct 05, 2021 at 11:45:42AM -0400, Michael S. Tsirkin wrote:
> > Looks like this can not be applied yet because the bypass bit
> > isn't in yet. what's up with that?
>
> The boot-bypass bit isn't a hard dependency for this ser
On Tue, Oct 05, 2021 at 11:45:42AM -0400, Michael S. Tsirkin wrote:
> Looks like this can not be applied yet because the bypass bit
> isn't in yet. what's up with that?
The boot-bypass bit isn't a hard dependency for this series, but it will
be needed for full support eventually. It will be delaye
Looks like this can not be applied yet because the bypass bit
isn't in yet. what's up with that?
--
MST
Allow instantiating a virtio-iommu device on ACPI systems by adding a
Virtual I/O Translation table (VIOT). Enable x86 support for VIOT.
Changes since v3 [1]:
* Cleaned the IOMMU-uniqueness checks. Added patch 6 to have a
single check on x86.
* Added patch 5 that allows to gracefully propagate e
: series
Message-id: 20210324205132.464899-1-vsement...@virtuozzo.com
Subject: [PATCH v4 00/11] 64bit block-layer: part II
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --lo
...@virtuozzo.com
Subject: [PATCH v4 00/11] 64bit block-layer: part II
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch
Patchew URL:
https://patchew.org/QEMU/20210324205132.464899-1-vsement...@virtuozzo.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210324205132.464899-1-vsement...@virtuozzo.com
Subject: [PATCH v4 00/11] 64bit
Hi all!
Here is part II of 64bit block-layer, when part I already landed
([PATCH v4 00/16] 64bit block-layer: part I
<20201211183934.169161-1-vsement...@virtuozzo.com>)
This is called v4 too, because it follows old
([PATCH v3 00/17] 64bit block-layer
<20200430111033.29980-1-vsement...@virtu
A virtio-mem device manages a memory region in guest physical address
space, represented as a single (currently large) memory region in QEMU,
mapped into system memory address space. Before the guest is allowed to use
memory blocks, it must coordinate with the hypervisor (plug blocks). After
a rebo
On Fri, Dec 04, 2020 at 12:48:46AM +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 fully functional version to get the ball
> going on
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 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
Patchew URL:
https://patchew.org/QEMU/20200921174118.39352-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200921174118.39352-1-richard.hender...@linaro.org
Subject: [PATCH v4 00/11
Patches lacking review:
0002-capstone-Update-to-upstream-next-branch.patch
0003-capstone-Require-version-4.0-from-a-system-librar.patch
0007-disas-Cleanup-plugin_disas.patch
0009-disas-Split-out-capstone-code-to-disas-capstone.c.patch
Changes for v4:
* Require v4.0 from the system library.
Got it.
On Wed, Sep 16, 2020 at 12:46 PM Igor Mammedov wrote:
>
> On Wed, 16 Sep 2020 11:43:24 +0530
> Ani Sinha wrote:
>
> > In v4 I have made the following changes:
> >
> > - a cosmetic change for patch #4. Commit log was updated as per Igor's
> > suggestion.
> > - patches #10 and #11 were ad
On Wed, 16 Sep 2020 11:43:24 +0530
Ani Sinha wrote:
> In v4 I have made the following changes:
>
> - a cosmetic change for patch #4. Commit log was updated as per Igor's
> suggestion.
> - patches #10 and #11 were added to unit test patch #9.
>
> The DSDT table after disabling hotplug on the ro
In v4 I have made the following changes:
- a cosmetic change for patch #4. Commit log was updated as per Igor's
suggestion.
- patches #10 and #11 were added to unit test patch #9.
The DSDT table after disabling hotplug on the root bus and the pci bridges is
shown here:
https://pastebin.ubuntu.
On Sun, 5 Jul 2020 19:10:46 +1000
David Gibson wrote:
> On Wed, Jul 01, 2020 at 06:43:35PM -0500, Lijun Pan wrote:
> > This patch series add several newly introduced 32/64-bit vector
> > instructions in Power ISA 3.1. Power ISA 3.1 flag is introduced in
> > this version. In v4 version, coding sty
On Wed, Jul 01, 2020 at 06:43:35PM -0500, Lijun Pan wrote:
> This patch series add several newly introduced 32/64-bit vector
> instructions in Power ISA 3.1. Power ISA 3.1 flag is introduced in
> this version. In v4 version, coding style issues are fixed, community
> reviews/suggestions are taken i
This patch series add several newly introduced 32/64-bit vector
instructions in Power ISA 3.1. Power ISA 3.1 flag is introduced in
this version. In v4 version, coding style issues are fixed, community
reviews/suggestions are taken into consideration.
Lijun Pan (11):
target/ppc: Introduce Power I
Missing review:
- patch #4 'rules.mak: Add startwith rule'
- patch #5 'rules.mak: Add base-arch rule'.
This series include generic patches I took of the KVM/ARM
specific series which will follow.
- List orphan accelerators in MAINTAINERS
- Add accel/Kconfig
- Allow targets to use their how Kconfi
On Fri, 2020-02-07 at 18:28 +, Dr. David Alan Gilbert wrote:
> * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > On Mon, 2020-02-03 at 19:57 +, Dr. David Alan Gilbert wrote:
> > > * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > > > This patch series is bunch of cleanups to the hmp monitor
* Maxim Levitsky (mlevi...@redhat.com) wrote:
> On Mon, 2020-02-03 at 19:57 +, Dr. David Alan Gilbert wrote:
> > * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > > This patch series is bunch of cleanups to the hmp monitor code.
> > > It mostly moves the blockdev related hmp handlers to its own
On Mon, 2020-02-03 at 19:57 +, Dr. David Alan Gilbert wrote:
> * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > This patch series is bunch of cleanups to the hmp monitor code.
> > It mostly moves the blockdev related hmp handlers to its own file,
> > and does some minor refactoring.
> >
> > N
* Maxim Levitsky (mlevi...@redhat.com) wrote:
> This patch series is bunch of cleanups to the hmp monitor code.
> It mostly moves the blockdev related hmp handlers to its own file,
> and does some minor refactoring.
>
> No functional changes expected.
You've still got the title marked as RFC - ar
This patch series is bunch of cleanups to the hmp monitor code.
It mostly moves the blockdev related hmp handlers to its own file,
and does some minor refactoring.
No functional changes expected.
Changes from V1:
* move the handlers to block/monitor/block-hmp-cmds.c
* tiny cleanup for the c
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
tha
1 - 100 of 235 matches
Mail list logo
