v1 was posted:
https://lore.kernel.org/qemu-devel/20250507231442.879619-1-pierrick.bouv...@linaro.org/
Regards,
Pierrick
On 5/7/25 4:32 AM, Daniel P. Berrangé wrote:
On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
Pierrick Bouvier writes:
[...]
I don't think we should think too much ahead for languages other than C,
for one, two, and even three reasons :)
I agree that thinking ahead too mu
On 5/7/25 12:55 AM, Markus Armbruster wrote:
[...]
- First, it's already broken because we rely on ifdef that won't be
there in Rust or Go.
I don't think it's broken. QAPI 'if' translates straightforwardly to C
#if, but that doesn't mean it cannot be translated to conditional
compilation / m
Daniel P. Berrangé writes:
> On Tue, Apr 29, 2025 at 09:43:24AM +0200, Markus Armbruster wrote:
>> Pierrick Bouvier writes:
>>
>> > After looking at the introspection code, I don't see any major blocker.
>> > We need to keep some of existing "if", as they are based on config-host,
>> > and sho
On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
> Pierrick Bouvier writes:
>
> [...]
>
> > I don't think we should think too much ahead for languages other than C,
> > for one, two, and even three reasons :)
>
> I agree that thinking ahead too much is a bad habit. So is thi
Pierrick Bouvier writes:
[...]
> I don't think we should think too much ahead for languages other than C,
> for one, two, and even three reasons :)
I agree that thinking ahead too much is a bad habit. So is thinking
ahead too little :)
> - First, it's already broken because we rely on ifdef
On 4/29/25 10:40 PM, Thomas Huth wrote:
On 29/04/2025 21.48, Pierrick Bouvier wrote:
...
I'm not keen to have a default target set, but it's a personal opinion based
on fear of "implicit smart choice hurts", so I'll be happy to change my mind
with a good argument for it.
No default target, ple
On 29/04/2025 21.48, Pierrick Bouvier wrote:
...
I'm not keen to have a default target set, but it's a personal opinion based
on fear of "implicit smart choice hurts", so I'll be happy to change my mind
with a good argument for it.
No default target, please! We've seen this with the default ma
On 4/29/25 12:57 PM, Pierrick Bouvier wrote:
On 4/29/25 2:35 AM, Philippe Mathieu-Daudé wrote:
If a distro wants to name a binary 'qemu-kvm' it can drop the
-target option and hard-wire its target_info() to a distro-specific
TargetInfo implementation, or &target_info_x86_64_system.
Having upd
On 4/29/25 2:35 AM, Philippe Mathieu-Daudé wrote:
If a distro wants to name a binary 'qemu-kvm' it can drop the
-target option and hard-wire its target_info() to a distro-specific
TargetInfo implementation, or &target_info_x86_64_system.
Having updated my Debian stable to next stable (trixie)
On 4/29/25 2:20 AM, Thomas Huth wrote:
On 29/04/2025 10.23, Markus Armbruster wrote:
...
I don't wish to derail this thread, but we've been dancing around the
question of how to best fix the target for some time. I think we should
talk about it for real.
Sure, and no problem about that, that
On 4/29/25 1:37 AM, Daniel P. Berrangé wrote:
On Tue, Apr 29, 2025 at 09:43:24AM +0200, Markus Armbruster wrote:
Pierrick Bouvier writes:
After looking at the introspection code, I don't see any major blocker.
We need to keep some of existing "if", as they are based on config-host,
and should
On 4/29/25 12:43 AM, Markus Armbruster wrote:
Pierrick Bouvier writes:
On 4/25/25 11:21 PM, Markus Armbruster wrote:
Trouble is some uses of the second kind are in QAPI conditionals. I can
see three options:
(1) Drop these conditionals.
(2) Replace them by run-time checks.
(3) Have target
On Tue, 29 Apr 2025, Markus Armbruster wrote:
Pierrick Bouvier writes:
On 4/28/25 4:07 AM, Markus Armbruster wrote:
Peter Krempa writes:
So what should libvirt do once multiple targets are supported?
How do we query CPUs for each of the supported targets?
It's kind of a similar question
On Tue, Apr 29, 2025 at 11:35:52AM +0200, Philippe Mathieu-Daudé wrote:
> On 29/4/25 10:23, Markus Armbruster wrote:
> > Pierrick Bouvier writes:
> >
> > > On 4/28/25 4:07 AM, Markus Armbruster wrote:
> > > > Peter Krempa writes:
> > > >
> > > > > So what should libvirt do once multiple targets
On 29/4/25 11:32, Daniel P. Berrangé wrote:
On Tue, Apr 29, 2025 at 11:20:59AM +0200, Thomas Huth via Devel wrote:
On 29/04/2025 10.23, Markus Armbruster wrote:
...
I don't wish to derail this thread, but we've been dancing around the
question of how to best fix the target for some time. I thi
On 29/4/25 10:23, Markus Armbruster wrote:
Pierrick Bouvier writes:
On 4/28/25 4:07 AM, Markus Armbruster wrote:
Peter Krempa writes:
So what should libvirt do once multiple targets are supported?
How do we query CPUs for each of the supported targets?
It's kind of a similar question w
On Tue, Apr 29, 2025 at 11:20:59AM +0200, Thomas Huth via Devel wrote:
> On 29/04/2025 10.23, Markus Armbruster wrote:
> ...
> > I don't wish to derail this thread, but we've been dancing around the
> > question of how to best fix the target for some time. I think we should
> > talk about it for r
On 29/04/2025 10.23, Markus Armbruster wrote:
...
I don't wish to derail this thread, but we've been dancing around the
question of how to best fix the target for some time. I think we should
talk about it for real.
Mind, this is not an objection to your larger "single binary" idea. It
could b
On Tue, Apr 29, 2025 at 09:43:24AM +0200, Markus Armbruster wrote:
> Pierrick Bouvier writes:
>
> > After looking at the introspection code, I don't see any major blocker.
> > We need to keep some of existing "if", as they are based on config-host,
> > and should apply.
> > We can introduce a ne
Pierrick Bouvier writes:
> On 4/28/25 4:07 AM, Markus Armbruster wrote:
>> Peter Krempa writes:
>>
>>> So what should libvirt do once multiple targets are supported?
>>>
>>> How do we query CPUs for each of the supported targets?
>>>
>
> It's kind of a similar question we have to solve now with
Pierrick Bouvier writes:
> On 4/25/25 11:21 PM, Markus Armbruster wrote:
>> Trouble is some uses of the second kind are in QAPI conditionals. I can
>> see three options:
>>
>> (1) Drop these conditionals.
>>
>> (2) Replace them by run-time checks.
>>
>> (3) Have target-specific QAPI-generated
On 4/28/25 12:54 PM, Stefan Hajnoczi wrote:
Sure.
Maybe there is a misunderstanding, but at this point, we are not trying
to invent anything new. We are just looking for a way to build QAPI
generated code only once, so it's possible to link together object files
coming from two different targets
On Mon, Apr 28, 2025 at 3:25 PM Pierrick Bouvier
wrote:
>
> Hi Stefan,
>
> On 4/28/25 11:14 AM, Stefan Hajnoczi wrote:
> > On Thu, Apr 24, 2025 at 2:35 PM Pierrick Bouvier
> > wrote:
> >> Feedback
> >>
> >>
> >> The goal of this series is to be spark a conversation around following
> >>
Hi Stefan,
On 4/28/25 11:14 AM, Stefan Hajnoczi wrote:
On Thu, Apr 24, 2025 at 2:35 PM Pierrick Bouvier
wrote:
Feedback
The goal of this series is to be spark a conversation around following topics:
- Would you be open to such an approach? (expose all code, and restrict commands
On Thu, Apr 24, 2025 at 2:35 PM Pierrick Bouvier
wrote:
> Feedback
>
>
> The goal of this series is to be spark a conversation around following topics:
>
> - Would you be open to such an approach? (expose all code, and restrict
> commands
> registered at runtime only for specific targe
On 4/28/25 4:07 AM, Markus Armbruster wrote:
Peter Krempa writes:
So what should libvirt do once multiple targets are supported?
How do we query CPUs for each of the supported targets?
It's kind of a similar question we have to solve now with QEMU code.
What happens when a symbol is duplic
On 4/28/25 3:25 AM, Peter Krempa wrote:
On Fri, Apr 25, 2025 at 14:07:34 -0700, Pierrick Bouvier wrote:
On 4/25/25 08:38, Markus Armbruster wrote:
Pierrick Bouvier writes:
Note: This RFC was posted to trigger a discussion around this topic, and it's
not expected to merge it as it is.
Contex
On 4/25/25 11:21 PM, Markus Armbruster wrote:
Trouble is some uses of the second kind are in QAPI conditionals. I can
see three options:
(1) Drop these conditionals.
(2) Replace them by run-time checks.
(3) Have target-specific QAPI-generated code for multiple targets
coexist in the sing
On 4/28/25 1:37 AM, Daniel P. Berrangé wrote:
On Fri, Apr 25, 2025 at 01:39:49PM -0700, Pierrick Bouvier wrote:
On 4/25/25 00:35, Daniel P. Berrangé wrote:
On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
Feedback
The goal of this series is to be spark a conversation
On 28/4/25 13:07, Markus Armbruster wrote:
Peter Krempa writes:
The second thing that libvirt does after 'query-version' is
'query-target'.
So what should libvirt do once multiple targets are supported?
How do we query CPUs for each of the supported targets?
Will the result be the same if
Peter Krempa writes:
> On Fri, Apr 25, 2025 at 17:38:44 +0200, Markus Armbruster via Devel wrote:
>> Pierrick Bouvier writes:
>
> [...]
>
>> To be precise: conditionals that use macros restricted to
>> target-specific code, i.e. the ones poisoned by exec/poison.h. Let's
>> call them target-spec
On Fri, Apr 25, 2025 at 14:07:34 -0700, Pierrick Bouvier wrote:
> On 4/25/25 08:38, Markus Armbruster wrote:
> > Pierrick Bouvier writes:
> >
> > > Note: This RFC was posted to trigger a discussion around this topic, and
> > > it's
> > > not expected to merge it as it is.
> > >
> > > Context
>
On Fri, Apr 25, 2025 at 17:38:44 +0200, Markus Armbruster via Devel wrote:
> Pierrick Bouvier writes:
[...]
> To be precise: conditionals that use macros restricted to
> target-specific code, i.e. the ones poisoned by exec/poison.h. Let's
> call them target-specific QAPI conditionals.
>
> The
On Fri, Apr 25, 2025 at 01:39:49PM -0700, Pierrick Bouvier wrote:
> On 4/25/25 00:35, Daniel P. Berrangé wrote:
> > On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
> > > Feedback
> > >
> > >
> > > The goal of this series is to be spark a conversation around following
>
Pierrick Bouvier writes:
> On 4/25/25 08:38, Markus Armbruster wrote:
>> Pierrick Bouvier writes:
>>
>>> Note: This RFC was posted to trigger a discussion around this topic, and
>>> it's
>>> not expected to merge it as it is.
>>>
>>> Context
>>> ===
>>>
>>> Linaro is working towards hetero
Philippe Mathieu-Daudé writes:
> On 25/4/25 09:35, Daniel P. Berrangé wrote:
>> On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
>>> Feedback
>>>
>>>
>>> The goal of this series is to be spark a conversation around following
>>> topics:
>>>
>>> - Would you be open to su
On 25/4/25 09:35, Daniel P. Berrangé wrote:
On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
Feedback
The goal of this series is to be spark a conversation around following topics:
- Would you be open to such an approach? (expose all code, and restrict commands
reg
On 4/25/25 14:07, Pierrick Bouvier wrote:
QAPI/QMP introspection has all commands and events, and all types
reachable from them. query-qmp-schema returns an array, where each
array element describes one command, event, or type. When a command,
event, or type is conditional in the schema, the el
On 4/25/25 08:38, Markus Armbruster wrote:
Pierrick Bouvier writes:
Note: This RFC was posted to trigger a discussion around this topic, and it's
not expected to merge it as it is.
Context
===
Linaro is working towards heterogeneous emulation, mixing several architectures
in a single QEM
On 4/25/25 00:35, Daniel P. Berrangé wrote:
On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
Feedback
The goal of this series is to be spark a conversation around following topics:
- Would you be open to such an approach? (expose all code, and restrict commands
reg
Pierrick Bouvier writes:
> Note: This RFC was posted to trigger a discussion around this topic, and it's
> not expected to merge it as it is.
>
> Context
> ===
>
> Linaro is working towards heterogeneous emulation, mixing several
> architectures
> in a single QEMU process. The first prerequi
On Thu, Apr 24, 2025 at 11:33:47AM -0700, Pierrick Bouvier wrote:
> Feedback
>
>
> The goal of this series is to be spark a conversation around following topics:
>
> - Would you be open to such an approach? (expose all code, and restrict
> commands
> registered at runtime only for spe
On 4/24/25 13:43, Philippe Mathieu-Daudé wrote:
What about function name clashes? I.e.:
389 ##
390 # @query-cpu-definitions:
391 #
392 # Return a list of supported virtual CPU definitions
393 #
394 # Returns: a list of CpuDefinitionInfo
395 #
396 # Since: 1.2
397 ##
398 { 'command': 'query-cpu-d
On 4/24/25 13:43, Philippe Mathieu-Daudé wrote:
What about function name clashes? I.e.:
389 ##
390 # @query-cpu-definitions:
391 #
392 # Return a list of supported virtual CPU definitions
393 #
394 # Returns: a list of CpuDefinitionInfo
395 #
396 # Since: 1.2
397 ##
398 { 'command': 'query-cpu-d
+Marc-André, Daniel & Dave
On 24/4/25 20:33, Pierrick Bouvier wrote:
Note: This RFC was posted to trigger a discussion around this topic, and it's
not expected to merge it as it is.
Context
===
Linaro is working towards heterogeneous emulation, mixing several architectures
in a single QEMU
On 24/4/25 20:33, Pierrick Bouvier wrote:
QAPI
QAPI generated files contain conditional clauses to define various structures,
enums, and commands only for specific targets. This forces files to be
compiled for every target. What we try to do here is to build them only once
instead.
In the
Note: This RFC was posted to trigger a discussion around this topic, and it's
not expected to merge it as it is.
Context
===
Linaro is working towards heterogeneous emulation, mixing several architectures
in a single QEMU process. The first prerequisite is to be able to build such a
binary, w
48 matches
Mail list logo
