On 22/11/2023 08.24, Markus Armbruster wrote:
Mutex @test_event_lock is held from fixture setup to teardown,
protecting global variable @test_event_data. But tests always run one
after the other, so this is superfluous. It also confuses Coverity.
Drop the mutex.
Fixes: CID 1527425
Signed-off-b
The series is pushed on top of vfio-next in the vfio-8.2 tree :
https://github.com/legoater/qemu/commits/vfio-8.2
with a little extra to deal with a PPC build failure.
Thanks Cédric. That's strange I didn't see this failure on my env
which has CONFIG_VFIO_PCI enabled by default for PPC.
On 22/11/2023 08.24, Markus Armbruster wrote:
The generated qapi_event_send_FOO() call an event emitter function.
It's test_qapi_event_emit() in this test. It compares the actual
event to the expected event, and sets a flag to record it was called.
The test functions set expected data and clear
On 22/11/2023 08.24, Markus Armbruster wrote:
The fixture buys us exactly nothing, as we need a global variable
anyway, for test_qapi_event_emit(). Drop it.
Signed-off-by: Markus Armbruster
---
tests/unit/test-qmp-event.c | 91 -
1 file changed, 30 insert
On 11/22/23 08:48, Harsh Prateek Bora wrote:
Initialize the machine specific max_cpus limit to a usable limit 4096.
Keeping between 4096 to 8192 will throw IRQ not free error due to XIVE
limitation and keeping beyond 8192 will hit assert in tcg_region_init
or spapr_xive_claim_irq.
The IRQ numbe
Let's use 'unsupported_configs' and 'tested_configs' here
instead of non-inclusive words.
Signed-off-by: Thomas Huth
---
v3: Rewording according to the suggestions of Daniel:
- Replaced "cipher not supported" with "config not supported"
- Replaced "not in LUKS_CONFIG" with "by user request"
On 11/21/23 20:09, Glenn Miles wrote:
Specs are available here:
https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
This is a simple model supporting the basic registers for GPIO
mode. The device also supports an interrupt output line but the
model does not yet support this.
Reviewe
On spapr, the max number of CPU IPIs are 4096 which is accounted during
spapr_irq_init but currently existing macro SPAPR_XIRQ_BASE is being
used to refer to that. Introducing SPAPR_NR_IPIS to refer to the range
of CPU IPIS which is being further used to initialize mc->max_cpus during
spapr_machine
On 11/22/23 14:06, Cédric Le Goater wrote:
On 11/22/23 08:48, Harsh Prateek Bora wrote:
Initialize the machine specific max_cpus limit to a usable limit 4096.
Keeping between 4096 to 8192 will throw IRQ not free error due to XIVE
limitation and keeping beyond 8192 will hit assert in tcg_regio
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which can be further
reused as appropriate for correct interpretation.
Signed-off-by: Harsh Prateek Bora
Suggeste
Initialize the machine specific max_cpus limit as per the maximum range
of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not
free error due to XIVE/XICS limitation and keeping beyond 8192 will hit
assert in tcg_region_init or spapr_xive_claim_irq.
Logs:
Without patch fix:
[root
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which can be further
reused as appropriate for correct interpretation.
Signed-off-by: Harsh Prateek Bora
Suggeste
Initialize the machine specific max_cpus limit as per the maximum range
of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not
free error due to XIVE/XICS limitation and keeping beyond 8192 will hit
assert in tcg_region_init or spapr_xive_claim_irq.
Logs:
Without patch fix:
[root
On spapr, the max number of CPU IPIs are 4096 which is accounted during
spapr_irq_init but currently existing macro SPAPR_XIRQ_BASE is being
used to refer to that. Introducing SPAPR_NR_IPIS to refer to the range
of CPU IPIS which is being further used to initialize mc->max_cpus during
spapr_machine
John Snow writes:
> On Tue, Nov 21, 2023, 8:33 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > It simplifies typing to mandate that entities will always have a name;
>> > to achieve this we can occasionally assign an internal name. This
>> > alleviates errors such as:
>> >
>> > qapi/
On Mon, Nov 20, 2023 at 04:44:50PM -0500, Peter Xu wrote:
> On Mon, Nov 20, 2023 at 03:55:54PM -0500, Steven Sistare wrote:
> > If we drop force, then all calls to vm_stop will completely stop the
> > suspended state, eg an hmp "stop" command. This causes two problems.
> > First, that is a change i
On Wed, Nov 22, 2023 at 09:40:00AM +0100, Thomas Huth wrote:
> Let's use 'unsupported_configs' and 'tested_configs' here
> instead of non-inclusive words.
>
> Signed-off-by: Thomas Huth
> ---
> v3: Rewording according to the suggestions of Daniel:
> - Replaced "cipher not supported" with "confi
Daniel P. Berrangé writes:
> On Tue, Nov 21, 2023 at 11:28:17AM -0500, John Snow wrote:
>> On Tue, Nov 21, 2023, 8:43 AM Daniel P. Berrangé
>> wrote:
>>
>> > On Tue, Nov 21, 2023 at 02:36:54PM +0100, Markus Armbruster wrote:
>> > > John Snow writes:
>> > >
>> > > > These methods should always
John Snow writes:
> On Tue, Nov 21, 2023, 9:17 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > lookup_type() is capable of returning None, but introspect.py isn't
>> > prepared for that. (And rightly so, if these built-in types are absent,
>> > something has gone hugely wrong.)
>> >
On Wed, Nov 22, 2023 at 10:50:47AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Tue, Nov 21, 2023 at 11:28:17AM -0500, John Snow wrote:
> >> On Tue, Nov 21, 2023, 8:43 AM Daniel P. Berrangé
> >> wrote:
> >>
> >> > On Tue, Nov 21, 2023 at 02:36:54PM +0100, Markus Armbrus
Marc-André Lureau writes:
> Hi
>
> On Tue, Nov 21, 2023 at 1:45 PM Thomas Huth wrote:
>>
>> On 21/11/2023 10.39, Marc-André Lureau wrote:
>> > Hi
>> >
>> > On Mon, Nov 20, 2023 at 5:36 PM Nicholas Piggin wrote:
>> >>
>> >> On Mon Nov 20, 2023 at 10:06 PM AEST, Marc-André Lureau wrote:
>> >>> Hi
Hi
On Thu, Nov 9, 2023 at 11:30 PM Philippe Mathieu-Daudé
wrote:
>
> If the UART back-end chardev doesn't drain data as fast as stdout
> does or blocks, buffer in the TX FIFO to try again later.
>
> This avoids having the IO-thread busy waiting on chardev back-ends,
> reported recently when testi
On 21/11/2023 12.47, Marc-André Lureau wrote:
Hi
On Tue, Nov 21, 2023 at 1:45 PM Thomas Huth wrote:
On 21/11/2023 10.39, Marc-André Lureau wrote:
Hi
On Mon, Nov 20, 2023 at 5:36 PM Nicholas Piggin wrote:
On Mon Nov 20, 2023 at 10:06 PM AEST, Marc-André Lureau wrote:
Hi
On Thu, Nov 16,
On Wed, Nov 22, 2023 at 02:31:29PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Thu, Nov 9, 2023 at 11:30 PM Philippe Mathieu-Daudé
> wrote:
> >
> > If the UART back-end chardev doesn't drain data as fast as stdout
> > does or blocks, buffer in the TX FIFO to try again later.
> >
> > This avoids h
On Wed, Nov 22, 2023 at 11:38:28AM +0100, Thomas Huth wrote:
> On 21/11/2023 12.47, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Nov 21, 2023 at 1:45 PM Thomas Huth wrote:
> > >
> > > On 21/11/2023 10.39, Marc-André Lureau wrote:
> > > > Hi
> > > >
> > > > On Mon, Nov 20, 2023 at 5:36 PM Nic
Hi Volodymyr,
On 21/11/23 23:10, Volodymyr Babchuk wrote:
was created by QEMU
Please do not split lines between subject and content. Rewrite the
full line. Preferably restrict the subject to 72 chars. Otherwise
your patch isn't displayed correctly in git tools.
Thanks,
Phil.
Xen PV devices
On 21/11/23 23:10, Volodymyr Babchuk wrote:
From: Oleksandr Tyshchenko
The number of vCPUs used for the IOREQ configuration (machine->smp.cpus)
should really match the system value as for each vCPU we setup a dedicated
evtchn for the communication with Xen at the runtime. This is needed
for the
On 22/11/23 10:28, Harsh Prateek Bora wrote:
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which can be further
reused as appropriate for correct interpretatio
Hi Harsh,
On 22/11/23 10:28, Harsh Prateek Bora wrote:
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which can be further
reused as appropriate for correct in
Hi Harsh,
On 22/11/23 10:28, Harsh Prateek Bora wrote:
Initialize the machine specific max_cpus limit as per the maximum range
of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not
free error due to XIVE/XICS limitation and keeping beyond 8192 will hit
assert in tcg_region_init
On 11/22/23 12:13, Philippe Mathieu-Daudé wrote:
Hi Harsh,
On 22/11/23 10:28, Harsh Prateek Bora wrote:
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which c
Hello Harsh,
Please add to your .git/config file:
[diff]
orderFile = /path/to/qemu/scripts/git.orderfile
On 11/22/23 10:28, Harsh Prateek Bora wrote:
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs propert
>-Original Message-
>From: Cédric Le Goater
>Sent: Wednesday, November 22, 2023 4:07 PM
>Subject: Re: [PATCH v7 00/27] vfio: Adopt iommufd
>
>
>>> The series is pushed on top of vfio-next in the vfio-8.2 tree :
>>>
>>>https://github.com/legoater/qemu/commits/vfio-8.2
>>>
>>> with a l
John Snow writes:
> On Tue, Nov 21, 2023, 9:09 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > We already take care to perform some type narrowing for arg_type and
>> > ret_type, but not in a way where mypy can utilize the result. A simple
>> > change to use a temporary variable help
John Snow writes:
> On Tue, Nov 21, 2023, 9:21 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > This function is a bit hard to type as-is; mypy needs some assertions to
>> > assist with the type narrowing.
>> >
>> > Signed-off-by: John Snow
>> > ---
>> > scripts/qapi/schema.py | 8 +
Hi,
> Even during the present patch review, while going through only the
> headers thus far, I've already said at least twice that we're going to
> have to be super careful about integer overflows and buffer overflows.
> Any such problem is no longer a guest<->guest privilege boundary breach
> b
On Mon, Nov 20, 2023 at 05:23:27PM -0600, Eric Blake wrote:
> > I'm interested in this use case, and I think that the method would be
> > as simple as this:
> >
> > 1. Decide a cluster size for the output qcow2 file.
> > 2. Read the input file once to determine which clusters need to be
> >all
MT is being detected based on "-M help" output, and we're searching for
the line ending with " (default)". However, in downstream one of the
MTs marked as deprecated might become the default, in which case this
logic breaks as the line would now end with " (default) (deprecated)".
To fix potential
In system mode emulation, some of translation blocks could be
interrupted on memory I/O operation. That leads to artificial
construction of another translation block that contains memory
operation only. If TCG plugin is not aware of that TB kind, it
attempts to insert execution callbacks either on
TCG Plugin callback to notify plugins when interrupt is triggered for
a vCpu. The plugin can optionally use this notification to see reason
of aborted instruction execution.
Signed-off-by: Mikhail Tyutin
---
accel/tcg/cpu-exec.c | 5 +
include/qemu/plugin-event.h | 1 +
include/qe
On 11/1/23 18:13, Denis V. Lunev wrote:
> On 11/1/23 16:23, Andrey Drobyshev wrote:
>> Currently we emit GUEST_PANICKED event in case kvm_vcpu_ioctl() returns
>> KVM_EXIT_SYSTEM_EVENT with the event type KVM_SYSTEM_EVENT_CRASH. Let's
>> extend this scenario and emit GUEST_PANICKED in case of an ab
On 11/15/23 16:12, Gerd Hoffmann wrote:
> This is the core code for guest <-> host communication. This accepts
> request messages from the guest, dispatches them to the service called,
> and sends back the response message.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/uefi/var-service-core.c | 3
> > 1. Memory IO operations force TCG to create special translation blocks to
> > process that memory load/store operation. The plugin gets notification for
> > this translation block as well, but instrumentation callbacks other than
> > memory ones are silently ignored. To make it correct, the plu
Hi,
> One option I've illustrated before is that have SVSM (or equiv)
> expose an encrypted storage service to EDK2. Given the proposed EDK2
> side protocol/modifications for variable storage, I wonder if it is
> viable for SVSM (or equiv) to replace QEMU in providing the backend
> storage impl
Albert Esteve writes:
Hello,
[...]
>
>> > Mutter patch:
>> > https://lists.freedesktop.org/archives/igt-dev/2023-July/058427.html
>>
>> Seems like this link is same as IGT? Copy-pasta fail maybe?
>>
>>
> Ah yes, my bad, this is the correct link:
> https://gitlab.gnome.org/GNOME/mutter/-/merge_r
Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in
inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still
required, because it can happen that stream.avail_in becomes zero
before coming across a return value of Z_STREAM_END in the loop.
This fixes the host->guest direction of
John Snow writes:
> There's more conditionals in here than we can reasonably pack into a
> terse little statement, so break it apart into something more explicit.
>
> (When would a built-in array ever cause a QAPISemError? I don't know,
> maybe never - but the type system wasn't happy all the sam
Hi
On Wed, Nov 22, 2023 at 5:00 PM Fiona Ebner wrote:
>
> Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in
> inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still
> required, because it can happen that stream.avail_in becomes zero
> before coming across a return value of Z
This patch allows to emulate the STM32L4x5 EXTI device.
It implements register access and software interruptions.
This is RFC since we still have troubles to make all tests pass.
More precisely, the line `g_assert_true(get_irq(GPIO_0_IRQ));` fails in
the software interrupts test. No irq seems to b
From: Arnaud Minier
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/arm/Kconfig| 1 +
hw/arm/stm32l4x5_soc.c| 65 ++-
hw/misc/Kconfig | 3 +
hw/misc/meson.build | 1 +
hw/misc/stm32l4x5_exti.c |
Am 22.11.23 um 14:06 schrieb Marc-André Lureau:
> Hi
>
> On Wed, Nov 22, 2023 at 5:00 PM Fiona Ebner wrote:
>>
>> Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in
>> inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still
>> required, because it can happen that stream.avail_
On 21/11/2023 08:43, Zhenzhong Duan wrote:
> Hi,
>
> Thanks all for giving guides and comments on previous series, this is
> the remaining part of the iommufd support.
>
> Besides suggested changes in v6, I'd like to highlight two changes
> for final review:
> 1. Instantiate can_be_deleted callba
John Snow writes:
> Differentiate between "actively in the process of checking" and
> "checking has completed". This allows us to clean up the types of some
> internal fields such as QAPISchemaObjectType's members field which
> currently uses "None" as a canary for determining if check has
> comp
John Snow writes:
> There are two related changes here:
>
> (1) We need to perform type narrowing for resolving the type of
> tag_member during check(), and
>
> (2) tag_member is a delayed initialization field, but we can hide it
> behind a property that raises an Exception if it's called
Ping for review?
Otherwise I plan to merge this when 9.0 opens.
Thanks, Phil.
On 5/9/23 16:51, Philippe Mathieu-Daudé wrote:
vAPIC isn't KVM specific, so having its name prefixed 'kvm'
is misleading. Rename it simply 'vapic'. Rename the single
function prefixed 'kvm'.
Signed-off-by: Philippe
Hi,
Kindly ping. :)
Thanks,
Chao
> -Original Messages-From:"Chao Du" Sent
> Time:2023-10-25 15:07:26 (Wednesday)To:qemu-devel@nongnu.org,
> qemu-arm@nongnu.orgCc:Subject:[PATCH] target/arm: kvm64: remove a redundant
> KVM_CAP_SET_GUEST_DEBUG probe
>
> The KVM_CAP_SET_GUEST_DEBUG is
Hi,
> > +struct uefi_var_policy {
> > +variable_policy_entry *entry;
> > +uint32_t entry_size;
> > +uint16_t *name;
> > +uint32_t name_size;
> > +uint32_t hashmarks
Hi Akihiro,
On 22/11/23 15:52, ~akihirosuda wrote:
From: Akihiro Suda
Update meson to the latest version, to fix
`ld: unknown options: --version` error on macOS
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1996
Signed-off-by: Akihiro Suda
---
python/scripts/vendor.py
On 21/11/2023 22:10, Volodymyr Babchuk wrote:
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather tha
On Wed, Nov 22, 2023 at 7:09 AM Markus Armbruster wrote:
>
> John Snow writes:
>
> > On Tue, Nov 21, 2023, 9:21 AM Markus Armbruster wrote:
> >
> >> John Snow writes:
> >>
> >> > This function is a bit hard to type as-is; mypy needs some assertions to
> >> > assist with the type narrowing.
> >>
On Wed, Nov 22, 2023 at 7:59 AM Markus Armbruster wrote:
>
> John Snow writes:
>
> > There's more conditionals in here than we can reasonably pack into a
> > terse little statement, so break it apart into something more explicit.
> >
> > (When would a built-in array ever cause a QAPISemError? I d
On Wed, Nov 22, 2023 at 9:05 AM Markus Armbruster wrote:
>
> John Snow writes:
>
> > There are two related changes here:
> >
> > (1) We need to perform type narrowing for resolving the type of
> > tag_member during check(), and
> >
> > (2) tag_member is a delayed initialization field, but we
On Wed, Nov 22, 2023 at 09:38:06AM +, Daniel P. Berrangé wrote:
> On Mon, Nov 20, 2023 at 04:44:50PM -0500, Peter Xu wrote:
> > On Mon, Nov 20, 2023 at 03:55:54PM -0500, Steven Sistare wrote:
> > > If we drop force, then all calls to vm_stop will completely stop the
> > > suspended state, eg an
Hi,
> - in general, we should filter out surrogate code points, for any use.
> any UCS2 string from the guest that contains a surrogate code point
> should be considered invalid, and the request should be rejected based
> just on that.
Something like this?
edk2 seems to be inconsistent with st
On 11/22/23 02:15, Chao Du wrote:
Hi,
Kindly ping. :)
Thanks,
Chao
-Original Messages-From:"Chao Du" Sent
Time:2023-10-25 15:07:26 (Wednesday)To:qemu-devel@nongnu.org,
qemu-arm@nongnu.orgCc:Subject:[PATCH] target/arm: kvm64: remove a redundant
KVM_CAP_SET_GUEST_DEBUG probe
The KV
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
On 21/11/2023 22:10, Volodymyr Babchuk wrote:
was created by QEMU
Xen PV devices in QEMU can be created in two ways: either by QEMU
itself, if they were passed via command line, or by Xen toolstack. In
the latter case, QEMU scans XenStore entries and configures devices
accordingly.
In the secon
On 21/11/2023 22:10, Volodymyr Babchuk wrote:
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather tha
On 21/11/2023 22:10, Volodymyr Babchuk wrote:
Add option to preserve owner when creating an entry in Xen Store. This
may be needed in cases when Qemu is working as device model in a
*may* be needed?
I don't undertstand why this patch is necessary and the commit comment
isn't really helping me
On 21/11/2023 22:10, Volodymyr Babchuk wrote:
From: Oleksandr Tyshchenko
Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to
inherit the owner of the directory.
Ah... so that's why the previous patch is there.
This is not the right way to fix it. The QEMU Xen support is *assumi
Did this lost this CVE-2022-36648 fix?
https://lists.nongnu.org/archive/html/qemu-devel/2022-06/msg04469.html
rocker_tlv_parse_nested could return early because of no group ids in
the group_tlvs. In such case tlvs is NULL; tlvs[i + 1] in the next
for-loop will deref the NULL pointer.
Signed-off
On Wed, Nov 22, 2023, 7:00 AM Markus Armbruster wrote:
> John Snow writes:
>
> > On Tue, Nov 21, 2023, 9:09 AM Markus Armbruster
> wrote:
> >
> >> John Snow writes:
> >>
> >> > We already take care to perform some type narrowing for arg_type and
> >> > ret_type, but not in a way where mypy can
LORE has better view/threading for this one,
https://lore.kernel.org/qemu-devel/20220624143912.1234427-1-mcasc...@redhat.com/
Which also links to https://gitlab.com/qemu-project/qemu/-/issues/1851
So basically, n/m.
/mjt
The ARM_CPU_IRQ/FIQ definitions are meant for the ARM CPU
QOM model. Move them to "cpu-qom.h" so any QOM code can
use them.
Signed-off-by: Philippe Mathieu-Daudé
---
Or do these definitions belong to cpu-defs.h?
---
target/arm/cpu-qom.h | 6 ++
target/arm/cpu.h | 6 --
2 files change
To allow GTIMER_* definitions to be used by non-ARM specific
hardware models, move them to a new target agnostic "cpu-defs.h"
header.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/cpu-defs.h | 19 +++
target/arm/cpu.h | 8 +---
hw/arm/bcm2836.c | 1 +
3 fil
Hi,
This series is a step toward having a single qemu-system-aarch64
binary for both ARM and Aarch64 variants.
First we add the TypeInfo::can_register() handler to QOM, to be
able to decide at runtime if a type can be registered. We'll
later use the target_aarch64_available() method to restrict s
All ARM CPUs have the 'start-powered-off' property since commit
5de164304a ("arm: Allow secondary KVM CPUs to be booted via PSCI").
Note: since commit c1b701587e ("target/arm: Move start-powered-off
property to generic CPUState"), all CPUs for all targets have it.
Signed-off-by: Philippe Mathieu-
Missed in commit 2d56be5a29 ("target: Declare
FOO_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'"). See
it for more details.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/cpu-qom.h | 3 +++
target/arm/cpu.h | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/target/arm/cpu-qom
Use the target_aarch64_available() method to restrict
Aarch64 specific models. They will only be added at runtime
if TARGET_AARCH64 is built in.
The Raspberry Pi models can now be built once for all targets.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/bcm2836.c | 5 +
hw/arm/raspi.c
Add a helper to decide at runtime whether a type can
be registered to the QOM framework or not.
Signed-off-by: Philippe Mathieu-Daudé
---
include/qom/object.h | 4
qom/object.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/include/qom/object.h b/include/qom/object.h
index
The 'mp-affinity' property is present since commit 15a21fe028
("target-arm: Add mp-affinity property for ARM CPU class").
Use it and remove a /* TODO */ comment. Since all ARM CPUs
have this property, use &error_abort, because this call can
not fail.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/
Use the target_aarch64_available() to build the ARM_GIC_KVM types
regardless the ARM/AARCH64 targets are selected, but restrict its
registration to TARGET_AARCH64 presence at runtime.
This will help to have a single binary running both ARM/Aarch64.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i
The ARMCPU type is forward declared as a pointer to all hw/ files.
Its declaration is restricted to target/arm/ files. By using a
pointer in BCM283XState instead of embedding the whole CPU state,
we don't need to include "cpu.h" which is target-specific.
Signed-off-by: Philippe Mathieu-Daudé
---
We want to build HW models once, but don't want to
register types when all prerequisites are satisfied. Add
the target_aarch64_available() to know at runtime whether
TARGET_AARCH64 is built-in.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/cpu-qom.h | 2 ++
target/arm/cpu.c | 9 ++
bcm2836_realize() is called by
- bcm2836_class_init() which sets:
bc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a7")
- bcm2837_class_init() which sets:
bc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a53")
Both Cortex-A7 / A53 have the ARM_FEATURE_CBAR set. If it isn't,
then this is a programmin
Since commit c1b701587e ("target/arm: Move start-powered-off
property to generic CPUState"), all target CPUs have the
'start-powered-off' property.
This object_property_set_bool() call can not fail. Use &error_abort
to simplify.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/cps.c | 7 +++---
xive2_regs.h only requires declarations from "qemu/bswap.h".
Include it instead of the huge target-specific "cpu.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/ppc/xive2_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/ppc/xive2_regs.h b/include/hw/
There is no universal BIOS, each machine needs a specific one.
Move the machine-specific definitions to each machine code and
remove this bogus header.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/mips/bios.h | 14 --
hw/mips/jazz.c | 10 +-
hw/mips/malta.c
On Sun, Nov 19, 2023 at 11:51:01PM +0100, Philippe Mathieu-Daudé wrote:
> Per https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
>
> Message Format
>
> The same message format is used for RXFIFO, TXFIFO, and TXHPB.
> Each message includes four words (16 bytes). Softwa
On Sun, Nov 19, 2023 at 11:51:02PM +0100, Philippe Mathieu-Daudé wrote:
> Per https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
>
> Message Format
>
> The same message format is used for RXFIFO, TXFIFO, and TXHPB.
> Each message includes four words (16 bytes). Softwa
On 11/22/23 19:39, Philippe Mathieu-Daudé wrote:
xive2_regs.h only requires declarations from "qemu/bswap.h".
Include it instead of the huge target-specific "cpu.h".
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
include/hw/ppc/xive2_regs.h | 2 +-
On Mon, Nov 20, 2023 at 06:18:06PM +0100, Philippe Mathieu-Daudé wrote:
> aio_context_set_aio_params() doesn't use its undocumented
> Error** argument. Remove it to simplify.
>
> Note this removes a use of "unchecked Error**" in
> iothread_set_aio_context_params().
>
> Signed-off-by: Philippe Mat
On Wed, Nov 22, 2023 at 08:45:56PM +0100, Francisco Iglesias wrote:
> On Sun, Nov 19, 2023 at 11:51:02PM +0100, Philippe Mathieu-Daudé wrote:
> > Per
> > https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
> >
> > Message Format
> >
> > The same message format is used f
Hi,
On Sun, Nov 19, 2023 at 11:51:01PM +0100, Philippe Mathieu-Daudé wrote:
> Per https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
>
> Message Format
>
> The same message format is used for RXFIFO, TXFIFO, and TXHPB.
> Each message includes four words (16 bytes). So
On Wed, 22 Nov 2023, Paul Durrant wrote:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
> > Add option to preserve owner when creating an entry in Xen Store. This
> > may be needed in cases when Qemu is working as device model in a
>
> *may* be needed?
>
> I don't undertstand why this patch is n
On Wed, 22 Nov 2023, Paul Durrant wrote:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
> > From: Oleksandr Tyshchenko
> >
> > Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to
> > inherit the owner of the directory.
>
> Ah... so that's why the previous patch is there.
>
> This
+Vikram
On Tue, 21 Nov 2023, Volodymyr Babchuk wrote:
> From: Oleksandr Tyshchenko
>
> The bridge is needed for virtio-pci support, as QEMU can emulate the
> whole bridge with any virtio-pci devices connected to it.
>
> This patch provides a flexible way to configure PCIe brige resources
> with
On Wed, 2023-11-22 at 17:05 +, Paul Durrant wrote:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
> > From: David Woodhouse
> >
> > This allows a XenDevice implementation to know whether it was created
> > by QEMU, or merely discovered in XenStore after the toolstack created
> > it. This wil
On Wed, 2023-11-22 at 17:03 +, Paul Durrant wrote:
>
> > This patch checks presence of xendev->backend to check if Xen PV
> > device is acting as a backend (i.e. it was configured by Xen
>
> Technally *all* XenDevice objects are backends.
Right. The key criterion is whether the backend was c
1 - 100 of 167 matches
Mail list logo
