Re: [PATCH] migration/dirtyrate: Fix segmentation fault

[Yong Huang]

On Tue, Apr 23, 2024 at 2:19 PM Masato Imai  wrote:

> When the KVM acceleration parameter is not set, executing calc_dirty_rate
> with the -r option results in a segmentation fault due to accessing a
> null kvm_state pointer in the kvm_dirty_rate_enabled function.
>

s/kvm_dirty_rate_enabled/kvm_dirty_ring_enabled/

This commit adds a check for kvm_enabled to prevent segmentation faults.
>
> Signed-off-by: Masato Imai 
> ---
>  migration/dirtyrate.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 1d2e85746f..4c1579c6e9 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -800,6 +800,8 @@ void qmp_calc_dirty_rate(int64_t calc_time,
>   * on the contrary, dirty bitmap mode is not.
>   */



 if (((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&
> +!kvm_enabled()) ||
> +((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&

 !kvm_dirty_ring_enabled()) ||
>  ((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP) &&

  kvm_dirty_ring_enabled())) {
>

This path may result in segmentation fault likewise, we can fix it together
by adding the following logic before this code:

if (!kvm_enabled() &&
   (mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING ||
mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP)) {
error_setg(errp, ...
return;
}



> --
> 2.34.1
>
>
Thanks for your work,
Yong

-- 
Best regards

Re: [PATCH] target/arm: Restrict translation disabled alignment check to VMSA

[Clément Chigot]

On Mon, Apr 22, 2024 at 11:02 PM Philippe Mathieu-Daudé
 wrote:
>
> On 22/4/24 19:09, Richard Henderson wrote:
> > On 4/22/24 10:07, Richard Henderson wrote:
> >> For cpus using PMSA, when the MPU is disabled, the default memory
> >> type is Normal, Non-cachable.
> >>
> >> Fixes: 59754f85ed3 ("target/arm: Do memory type alignment check when
> >> translation disabled")
> >> Reported-by: Clément Chigot 
> >> Signed-off-by: Richard Henderson 
> >> ---
> >>
> >> Since v9 will likely be tagged tomorrow without this fixed,
> >> Cc: qemu-sta...@nongnu.org
> >>
> >> ---
> >>   target/arm/tcg/hflags.c | 12 ++--
> >>   1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/target/arm/tcg/hflags.c b/target/arm/tcg/hflags.c
> >> index 5da1b0fc1d..66de30b828 100644
> >> --- a/target/arm/tcg/hflags.c
> >> +++ b/target/arm/tcg/hflags.c
> >> @@ -38,8 +38,16 @@ static bool aprofile_require_alignment(CPUARMState
> >> *env, int el, uint64_t sctlr)
> >>   }
> >>   /*
> >> - * If translation is disabled, then the default memory type is
> >> - * Device(-nGnRnE) instead of Normal, which requires that alignment
> >> + * With PMSA, when the MPU is disabled, all memory types in the
> >> + * default map is Normal.
> >> + */
> >> +if (arm_feature(env, ARM_FEATURE_PMSA)) {
> >> +return false;
> >> +}
> >> +
> >> +/*
> >> + * With VMSA, if translation is disabled, then the default memory
> >> type
> >> + * is Device(-nGnRnE) instead of Normal, which requires that
> >> alignment
> >>* be enforced.  Since this affects all ram, it is most efficient
> >>* to handle this during translation.
> >>*/
> >
> > Oh, I meant to add: since the armv7 manual has both VMSA and PMSA
> > sections, and the language about default Device type and alignment
> > traps, is in the VMSA section.
>
> To the best of my knowledge,
> Reviewed-by: Philippe Mathieu-Daudé 

Thanks for the patch.

Tested-by: Clément Chigot 

Re: [PATCH 00/27] Add qapi-domain Sphinx extension

[Markus Armbruster]

John Snow  writes:

> On Mon, Apr 22, 2024 at 5:20 AM Markus Armbruster  wrote:
>>
>> John Snow  writes:
>>
>> > On Fri, Apr 19, 2024, 10:45 AM Markus Armbruster  wrote:
>> >
>> >> John Snow  writes:
>> >>
>> >> > This series adds a new qapi-domain extension for Sphinx, which adds a
>> >> > series of custom directives for documenting QAPI definitions.
>> >> >
>> >> > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/1259566476
>> >> >
>> >> > (Link to a demo HTML page at the end of this cover letter, but I want
>> >> > you to read the cover letter first to explain what you're seeing.)
>> >> >
>> >> > This adds a new QAPI Index page, cross-references for QMP commands,
>> >> > events, and data types, and improves the aesthetics of the QAPI/QMP
>> >> > documentation.
>> >>
>> >> Cross-references alone will be a *massive* improvement!  I'm sure
>> >> readers will appreciate better looks and an index, too.
>> >>
>> >> > This series adds only the new ReST syntax, *not* the autogenerator. The
>> >> > ReST syntax used in this series is, in general, not intended for anyone
>> >> > to actually write by hand. This mimics how Sphinx's own autodoc
>> >> > extension generates Python domain directives, which are then re-parsed
>> >> > to produce the final result.
>> >> >
>> >> > I have prototyped such a generator, but it isn't ready for inclusion
>> >> > yet. (Rest assured: error context reporting is preserved down to the
>> >> > line, even in generated ReST. There is no loss in usability for this
>> >> > approach. It will likely either supplant qapidoc.py or heavily alter
>> >> > it.) The generator requires only extremely minor changes to
>> >> > scripts/qapi/parser.py to preserve nested indentation and provide more
>> >> > accurate line information. It is less invasive than you may
>> >> > fear. Relying on a secondary ReST parse phase eliminates much of the
>> >> > complexity of qapidoc.py. Sleep soundly.
>> >>
>> >> I'm a Sphinx noob.  Let me paraphrase you to make sure I understand.
>> >>
>> >> You proprose to generate formatted documentation in two steps:
>> >>
>> >> • First, the QAPI generator generates .rst from the QAPI schema.  The
>> >>   generated .rst makes use of a custom directives.
>> >>
>> >
>> > Yes, but this .rst file is built in-memory and never makes it to disk, like
>> > Sphinx's autodoc for Python.
>>
>> Makes sense.
>>
>> > (We can add a debug knob to log it or save it out to disk if needed.)
>>
>> Likely useful at least occasionally.
>
> Yep, python's autodoc has such a knob to use the debugging log for
> this. I just want to point out that avoiding the intermediate file
> on-disk is actually the mechanism by which I can preserve source
> lines, so this is how it's gotta be.
>
> I build an intermediate doc in-memory with source filenames and source
> lines along with the modified doc block content so that ReST errors
> can be tracked back directly to the QAPI json files. If we saved to
> disk and parsed that, it'd obliterate that information.

Sounds just fine to me.

>> >> • Second, Sphinx turns the .rst into formatted documentation.  A Sphinx
>> >>   qapi-domain extension implements the custom directives
>> >
>> > Yes.
>> >
>> >
>> >> This mirrors how Sphinx works for Python docs.  Which is its original
>> >> use case.
>> >>
>> >> Your series demonstrates the second step, with test input you wrote
>> >> manually.
>> >>
>> >> You have code for the first step, but you'd prefer to show it later.
>> >
>> > Right, it's not fully finished, although I have events, commands, and
>> > objects working. Unions, Alternates and Events need work.
>> >
>> >
>> >> Fair?
>> >
>> > Bingo!
>>
>> Thanks!
>>
>> >> > The purpose of sending this series in its current form is largely to
>> >> > solicit feedback on general aesthetics, layout, and features. Sphinx is
>> >> > a wily beast, and feedback at this stage will dictate how and where
>> >> > certain features are implemented.
>> >>
>> >> I'd appreciate help with that.  Opinions?
>> >
>> >
>> >> > A goal for this syntax (and the generator) is to fully in-line all
>> >> > command/event/object members, inherited or local, boxed or not, branched
>> >> > or not. This should provide a boon to using these docs as a reference,
>> >> > because users will not have to grep around the page looking for various
>> >> > types, branches, or inherited members. Any arguments types will be
>> >> > hyperlinked to their definition, further aiding usability. Commands can
>> >> > be hotlinked from anywhere else in the manual, and will provide a
>> >> > complete reference directly on the first screenful of information.
>> >>
>> >> Let me elaborate a bit here.
>> >>
>> >> A command's arguments can be specified inline, like so:
>> >>
>> >> { 'command': 'job-cancel', 'data': { 'id': 'str' } }
>> >>
>> >> The arguments are then documented right with the command.
>> >>
>> >> But they can also be specified by referencing an object type, like so:
>> >>
>> >> { 'command': 'block-dirty

Re: Missing features in QEMU SapphireRapid definition

[Wang, Lei]

Hi Manish,

Thanks for the information. It seems those 3 features are missing in the SPR CPU
Model definition, we are currently polishing our new SPR CPU Model version, you
can launch the SPR CPU Model using:

-cpu SapphireRapids,+cldemote,+movdiri,+movdir64b

as a workaround and sorry for the inconvenience:)

Thanks,
Lei

On 4/23/2024 14:57, Manish Mishra wrote:
> Hi Everyone,
> 
> We see few features like movdiri, movdiri64b, cldemote are present on
> SapphireRapid nodes and are also mentioned as supported in intel manual.  But
> these are missing from the QEMU definition of SapphireRapid CPUs
> https://github.com/qemu/qemu/commit/7eb061b06e97af9a8da7f31b839d78997ae737fc
> .
> There may be other features too missing but we were particularly interested in
> these three. So just wanted to understand if there is any reason for this.  
> Any
> help on this will be really appreciated. 😊
> 
> Thanks
> 
> Manish Mishra
> 
>  
> 

Re: Missing features in QEMU SapphireRapid definition

[Manish Mishra]

Thanks Wang Lie. Yes sure will do same until we have new version.

Thanks
Manish Mishra

From: Wang, Lei 
Date: Tuesday, 23 April 2024 at 12:50 PM
To: Manish Mishra , qemu-devel@nongnu.org 

Cc: christopher.r.blev...@intel.com , 
robert...@linux.intel.com 
Subject: Re: Missing features in QEMU SapphireRapid definition
!---|
  CAUTION: External Email

|---!

Hi Manish,

Thanks for the information. It seems those 3 features are missing in the SPR CPU
Model definition, we are currently polishing our new SPR CPU Model version, you
can launch the SPR CPU Model using:

-cpu SapphireRapids,+cldemote,+movdiri,+movdir64b

as a workaround and sorry for the inconvenience:)

Thanks,
Lei

On 4/23/2024 14:57, Manish Mishra wrote:
> Hi Everyone,
>
> We see few features like movdiri, movdiri64b, cldemote are present on
> SapphireRapid nodes and are also mentioned as supported in intel manual.  But
> these are missing from the QEMU definition of SapphireRapid CPUs
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_qemu_qemu_commit_7eb061b06e97af9a8da7f31b839d78997ae737fc&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=qsXsvA9Qo3ML3oCccH0qSA3BBq4544AcaMXOeabvdeje0HQH32tdJGQbXZ6EZPhX&s=HqvoOOETdcRl9-Ki8PWb-pjrF0lBMIm1CDV8T0eJt8g&e=
>   >.
> There may be other features too missing but we were particularly interested in
> these three. So just wanted to understand if there is any reason for this.  
> Any
> help on this will be really appreciated. 😊
>
> Thanks
>
> Manish Mishra
>
>
>

Re: [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines

[Marcin Juszkiewicz]

W dniu 22.04.2024 o 17:37, Marcin Juszkiewicz pisze:

It also seems to be hardcoded in TF-A's support for the virt
board too, annoyingly.


I looked at it and it seems that TF-A can just read what is in 
CNTFRQ_EL0 instead of hardcoding the value.


Submitted patch:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/28313
refactor(qemu): do not hardcode counter frequency [NEW]


Change is now merged.

Re: [PATCH 00/27] Add qapi-domain Sphinx extension

[Markus Armbruster]

John Snow  writes:

> On Mon, Apr 22, 2024 at 12:38 PM John Snow  wrote:
>>
>> On Mon, Apr 22, 2024 at 5:20 AM Markus Armbruster  wrote:
>> >
>> > John Snow  writes:
>> >
>> > > On Fri, Apr 19, 2024, 10:45 AM Markus Armbruster  
>> > > wrote:
>> > >
>> > >> John Snow  writes:
>> > >>
>> > >> > This series adds a new qapi-domain extension for Sphinx, which adds a
>> > >> > series of custom directives for documenting QAPI definitions.

[...]

>> > >> > Known issues / points of interest:

[...]

>> > >> > - Inlining all members means there is some ambiguity on what to do 
>> > >> > with
>> > >> >   doc block sections on inlined entities; features and members have an
>> > >> >   obvious home - body, since, and misc sections are not as obvious on
>> > >> >   how to handle. This will feature more prominently in the generator
>> > >> >   series.
>> > >>
>> > >> Yes, this is a real problem.
>> > >>
>> > >> The member documentation gets written in the context of the type.  It
>> > >> may make sense only in that context.  Inlining copies it into a
>> > >> different context.
>> > >>
>> > >> Features may need to combine.  Say a command's arguments are a union
>> > >> type, and several branches of the union both contain deprecated members.
>> > >> These branch types all document feature @deprecated.  Simply inlining
>> > >> their feature documentation results in feature @deprecated documented
>> > >> several times.  Ugh.  Combining them would be better.  But how?  Do we
>> > >> need to rethink how we document features?
>> > >
>> > > To be honest, I figured I'd plow ahead and then find the counter-examples
>> > > programmatically and decide what to do once I had my pile of edge cases.
>> > >
>> > > It might involve rewriting docs in some places, but I think the usability
>> > > win is completely worth the hassle.
>> > >
>> > > It's possible there might be some rework needed to maximize cogency of 
>> > > the
>> > > generated docs, but I think prioritizing a user-facing reference for QMP 
>> > > is
>> > > the objectively correct end goal and I'm more than happy to work 
>> > > backwards
>> > > from that desired state.
>> >
>> > I'm not disputing the idea that documenting the arguments right with the
>> > command is good.  I'm merely pointing out obstacles to pulling that off.
>> >
>> > Adjusting existing documentation is only half the battle.  The other
>> > half is making sure documentation stays adjusted.  We may have to come
>> > up with new documentation rules, and ways to enforce them.
>>
>> For the sake of argument, let's say we forbid everything except
>> arg/features from definitions destined to be used as base/inherited
>> types. This would be very easy to enforce at the qapidoc level where
>> the doc inlining is performed by yelping when the base type contains
>> additional documentation sections.
>>
>> Now, in the real world, maybe sometimes those sections are useful and
>> we don't want to get rid of them, esp. because they may contain useful
>> documentation that we don't want to duplicate in the source files.
>>
>> My plan is to just forbid them at first and enumerate the cases where
>> they occur, then decide which ones are better off being moved
>> elsewhere or explicitly tolerated. The generator's tolerance can be
>> adjusted accordingly and we can formulate a rule for exactly how doc
>> blocks are combined and merged. I think it won't be a problem to
>> enforce it programmatically.
>>
>> I'll get back to you on how often and precisely where these cases
>> occur so you can take a look and see how you feel.
>>
>
> For a warmup, let's look at every unique instance of non-empty
> paragraph text on an object that is used as a base anywhere:
>
> Warning: AudiodevPerDirectionOptions - inlined paragraph
> Warning: BlockdevOptionsCurlBase - inlined paragraph
> Warning: BlockdevOptionsGenericCOWFormat - inlined paragraph
> Warning: BlockdevOptionsGenericFormat - inlined paragraph
> Warning: BlockExportOptionsNbdBase - inlined paragraph
> Warning: BlockNodeInfo - inlined paragraph
> Warning: ChardevCommon - inlined paragraph
> Warning: CpuInstanceProperties - inlined paragraph
> Warning: CryptodevBackendProperties - inlined paragraph
> Warning: EventLoopBaseProperties - inlined paragraph
> Warning: MemoryBackendProperties - inlined paragraph
> Warning: NetfilterProperties - inlined paragraph
> Warning: QCryptoBlockAmendOptionsLUKS - inlined paragraph
> Warning: QCryptoBlockCreateOptionsLUKS - inlined paragraph
> Warning: QCryptoBlockInfoBase - inlined paragraph
> Warning: QCryptoBlockOptionsBase - inlined paragraph
> Warning: QCryptoBlockOptionsLUKS - inlined paragraph
> Warning: RngProperties - inlined paragraph
> Warning: SecretCommonProperties - inlined paragraph
> Warning: SpiceBasicInfo - inlined paragraph
> Warning: TlsCredsProperties - inlined paragraph
> Warning: VncBasicInfo - inlined paragraph
>
> There's 22 instances.
>
> Let's look at what they say:
>
> AudiodevPerDirectionOptions: "General audio backe

Re: [PATCH] target/i386/translate.c: always write 32-bits for SGDT and SIDT

[Philippe Mathieu-Daudé]

On 22/4/24 21:03, Volker Rümelin wrote:

Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:

On 20/04/2024 02:21, Richard Henderson wrote:


On 4/19/24 12:51, Mark Cave-Ayland wrote:

The various Intel CPU manuals claim that SGDT and SIDT can write
either 24-bits
or 32-bits depending upon the operand size, but this is incorrect.
Not only do
the Intel CPU manuals give contradictory information between processor
revisions, but this information doesn't even match real-life behaviour.

In fact, tests on real hardware show that the CPU always writes
32-bits for SGDT
and SIDT, and this behaviour is required for at least OS/2 Warp and
WFW 3.11 with
Win32s to function correctly. Remove the masking applied due to the
operand size
for SGDT and SIDT so that the TCG behaviour matches the behaviour on
real
hardware.

Signed-off-by: Mark Cave-Ayland 
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198

--
MCA: Whilst I don't have a copy of OS/2 Warp handy, I've confirmed
that this
patch fixes the issue in WFW 3.11 with Win32s. For more technical
information I
highly recommend the excellent write-up at
https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/.
---
   target/i386/tcg/translate.c | 14 --
   1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 76a42c679c..3026eb6774 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -5846,9 +5846,10 @@ static bool disas_insn(DisasContext *s,
CPUState *cpu)
   gen_op_st_v(s, MO_16, s->T0, s->A0);
   gen_add_A0_im(s, 2);
   tcg_gen_ld_tl(s->T0, tcg_env, offsetof(CPUX86State,
gdt.base));
-    if (dflag == MO_16) {
-    tcg_gen_andi_tl(s->T0, s->T0, 0xff);
-    }
+    /*
+ * NB: Despite claims to the contrary in Intel CPU
documentation,
+ * all 32-bits are written regardless of operand size.
+ */


Current documentation agrees that all 32 bits are written, so I don't
think you need this comment:


Ah that's good to know the docs are now correct. I added the comment
as there was a lot of conflicting information around for older CPUs so
I thought it was worth an explicit mention.

If everyone agrees a version without comments is preferable, I can
re-send an updated version without them included.



Hi Mark,

I wouldn't remove the comment.

Quote from the Intel® 64 and IA-32 Architectures Software Developer’s
Manual Volume 2B: Instruction Set Reference, M-U March 2024:

IA-32 Architecture Compatibility
The 16-bit form of SGDT is compatible with the Intel 286 processor if
the upper 8 bits are not referenced. The Intel 286 processor fills these
bits with 1s; processor generations later than the Intel 286 processor
fill these bits with 0s.


Is that that OS/2 Warp and WFW 3.11 expect a 286 CPU? QEMU starts
modelling the 486, do we want to consider down to the 286?


Intel still claims the upper 8 bits are filled with 0s, but the
Operation pseudo code below is correct. The same is true for SIDT.

With best regards,
Volker


    IF OperandSize =16 or OperandSize = 32 (* Legacy or Compatibility
Mode *)
  THEN
    DEST[0:15] := GDTR(Limit);
    DEST[16:47] := GDTR(Base); (* Full 32-bit base address stored *)
    FI;


Anyway,
Reviewed-by: Richard Henderson 


Thanks!


ATB,

Mark.

Re: [PATCH v1 3/4] virtio-snd: factor card removal out of unrealize()

[Philippe Mathieu-Daudé]

On 22/4/24 15:27, Philippe Mathieu-Daudé wrote:

On 22/4/24 14:52, Manos Pitsidianakis wrote:

Extract audio card removal logic out of the device unrealize callback so
that it can be re-used in follow up commits.

Signed-off-by: Manos Pitsidianakis 
---
  hw/audio/virtio-snd.c | 20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)




-static void virtio_snd_unrealize(DeviceState *dev)
+/* Remove audio card and cleanup streams. */
+static void virtio_snd_unsetup(VirtIOSound *vsnd)


Maybe s/unsetup/cleanup/?


Or 'teardown'?




  {
-    VirtIODevice *vdev = VIRTIO_DEVICE(dev);
-    VirtIOSound *vsnd = VIRTIO_SND(dev);
  VirtIOSoundPCMStream *stream;
-    qemu_del_vm_change_state_handler(vsnd->vmstate);
-    trace_virtio_snd_unrealize(vsnd);
-
  if (vsnd->pcm) {
  if (vsnd->pcm->streams) {
  for (uint32_t i = 0; i < vsnd->snd_conf.streams; i++) {
@@ -1370,6 +1366,18 @@ static void virtio_snd_unrealize(DeviceState *dev)
  vsnd->pcm = NULL;
  }
  AUD_remove_card(&vsnd->card);
+}

Re: [PATCH intel_iommu 3/7] intel_iommu: make types match

[Philippe Mathieu-Daudé]

On 23/4/24 07:05, CLEMENT MATHIEU--DRIF wrote:


On 22/04/2024 19:03, Philippe Mathieu-Daudé wrote:

On 22/4/24 17:52, CLEMENT MATHIEU--DRIF wrote:

The 'level' field in vtd_iotlb_key is an uint8_t.
We don't need to store level as an int in vtd_lookup_iotlb

Signed-off-by: Clément Mathieu--Drif 
---
   hw/i386/intel_iommu.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 6f1364b3fd..ba545590b1 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -333,7 +333,7 @@ static VTDIOTLBEntry
*vtd_lookup_iotlb(IntelIOMMUState *s, uint16_t source_id,
   {
   struct vtd_iotlb_key key;
   VTDIOTLBEntry *entry;
-    int level;
+    uint8_t level;


Or simply 'unsigned' up to vtd_slpt_level_shift()?

vtd_iotlb_key.level is an uint8_t, just avoiding a warning here


What warning?

Re: [PATCH] target/i386/translate.c: always write 32-bits for SGDT and SIDT

[Daniel P . Berrangé]

On Tue, Apr 23, 2024 at 10:15:57AM +0200, Philippe Mathieu-Daudé wrote:
> On 22/4/24 21:03, Volker Rümelin wrote:
> > Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
> > > On 20/04/2024 02:21, Richard Henderson wrote:
> > > 
> > > > On 4/19/24 12:51, Mark Cave-Ayland wrote:
> > > > > The various Intel CPU manuals claim that SGDT and SIDT can write
> > > > > either 24-bits
> > > > > or 32-bits depending upon the operand size, but this is incorrect.
> > > > > Not only do
> > > > > the Intel CPU manuals give contradictory information between processor
> > > > > revisions, but this information doesn't even match real-life 
> > > > > behaviour.
> > > > > 
> > > > > In fact, tests on real hardware show that the CPU always writes
> > > > > 32-bits for SGDT
> > > > > and SIDT, and this behaviour is required for at least OS/2 Warp and
> > > > > WFW 3.11 with
> > > > > Win32s to function correctly. Remove the masking applied due to the
> > > > > operand size
> > > > > for SGDT and SIDT so that the TCG behaviour matches the behaviour on
> > > > > real
> > > > > hardware.
> > > > > 
> > > > > Signed-off-by: Mark Cave-Ayland 
> > > > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198
> > > > > 
> > > > > -- 
> > > > > MCA: Whilst I don't have a copy of OS/2 Warp handy, I've confirmed
> > > > > that this
> > > > > patch fixes the issue in WFW 3.11 with Win32s. For more technical
> > > > > information I
> > > > > highly recommend the excellent write-up at
> > > > > https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/.
> > > > > ---
> > > > >    target/i386/tcg/translate.c | 14 --
> > > > >    1 file changed, 8 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
> > > > > index 76a42c679c..3026eb6774 100644
> > > > > --- a/target/i386/tcg/translate.c
> > > > > +++ b/target/i386/tcg/translate.c
> > > > > @@ -5846,9 +5846,10 @@ static bool disas_insn(DisasContext *s,
> > > > > CPUState *cpu)
> > > > >    gen_op_st_v(s, MO_16, s->T0, s->A0);
> > > > >    gen_add_A0_im(s, 2);
> > > > >    tcg_gen_ld_tl(s->T0, tcg_env, offsetof(CPUX86State,
> > > > > gdt.base));
> > > > > -    if (dflag == MO_16) {
> > > > > -    tcg_gen_andi_tl(s->T0, s->T0, 0xff);
> > > > > -    }
> > > > > +    /*
> > > > > + * NB: Despite claims to the contrary in Intel CPU
> > > > > documentation,
> > > > > + * all 32-bits are written regardless of operand 
> > > > > size.
> > > > > + */
> > > > 
> > > > Current documentation agrees that all 32 bits are written, so I don't
> > > > think you need this comment:
> > > 
> > > Ah that's good to know the docs are now correct. I added the comment
> > > as there was a lot of conflicting information around for older CPUs so
> > > I thought it was worth an explicit mention.
> > > 
> > > If everyone agrees a version without comments is preferable, I can
> > > re-send an updated version without them included.
> > > 
> > 
> > Hi Mark,
> > 
> > I wouldn't remove the comment.
> > 
> > Quote from the Intel® 64 and IA-32 Architectures Software Developer’s
> > Manual Volume 2B: Instruction Set Reference, M-U March 2024:
> > 
> > IA-32 Architecture Compatibility
> > The 16-bit form of SGDT is compatible with the Intel 286 processor if
> > the upper 8 bits are not referenced. The Intel 286 processor fills these
> > bits with 1s; processor generations later than the Intel 286 processor
> > fill these bits with 0s.
> 
> Is that that OS/2 Warp and WFW 3.11 expect a 286 CPU? QEMU starts
> modelling the 486, do we want to consider down to the 286?

Depends on the versions you're talking about. From what I can gather,
OS/2 1.x targetted i286, OS/2 2.x & 3.x targetted i386, and OS/2 4.0
Warp targetted i486, while WFW 3.11 was i386.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH v8 00/11] Support blob memory and venus on qemu

[Alex Bennée]

Dmitry Osipenko  writes:

> Hello,
>
> This series enables Vulkan Venus context support on virtio-gpu.
>
> All virglrender and almost all Linux kernel prerequisite changes
> needed by Venus are already in upstream. For kernel there is a pending
> KVM patchset that fixes mapping of compound pages needed for DRM drivers
> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
> from Qemu.
>
> [1]
> https://lore.kernel.org/kvm/20240229025759.1187910-1-steve...@google.com/

Following the link for the TTM/KVM patches on the kernel side points at
changes for AMD cards getting NAK'ed so I'm a little confused as to what
parts are needed.

Is this only relevant for ensuring the virtual mappings to the
underlying hardware aren't moved around when KVM is exporting those
pages to the guest?

Our interest is in Xen which obviously mediates everything through stage
2 mappings to from the real PA to the IPA the domains see. However AIUI
all the blob allocation is managed by the GEM/TTM layer of whichever
kernel is responsible for driving the GPU. Does this layer work with
kernel vaddr or the underlying IPA of the resources? We shouldn't
expect the IPA to change between allocations should we?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v3] hw/audio/virtio-snd: Use device endianness instead of target one

[Manos Pitsidianakis]

On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin  wrote:
>
> On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
> > On 22/4/24 23:02, Michael S. Tsirkin wrote:
> > > On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> > > > Since VirtIO devices can change endianness at runtime,
> > > > we need to use the device endianness, not the target
> > > > one.
> > > >
> > > > Cc: qemu-sta...@nongnu.org
> > > > Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
> > > > Signed-off-by: Philippe Mathieu-Daudé 
> > >
> > >
> > >
> > > This is all completely bogus. Virtio SND is from Virtio 1.0 only.
> > > It is unconditionally little endian.


This part of the code is for PCM frames (raw bytes), not virtio spec
fields (which indeed must be LE in modern VIRTIO).

Re: [PATCH] target/i386/translate.c: always write 32-bits for SGDT and SIDT

[Paolo Bonzini]

On Mon, Apr 22, 2024 at 9:10 PM Volker Rümelin  wrote:
>
> Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
> >> Current documentation agrees that all 32 bits are written, so I don't
> >> think you need this comment:
> >
> > Ah that's good to know the docs are now correct. I added the comment
> > as there was a lot of conflicting information around for older CPUs so
> > I thought it was worth an explicit mention.
>
> Quote from the Intel® 64 and IA-32 Architectures Software Developer’s
> Manual Volume 2B: Instruction Set Reference, M-U March 2024:
>
> IA-32 Architecture Compatibility
> The 16-bit form of SGDT is compatible with the Intel 286 processor if
> the upper 8 bits are not referenced. The Intel 286 processor fills these
> bits with 1s; processor generations later than the Intel 286 processor
> fill these bits with 0s.
>
> Intel still claims the upper 8 bits are filled with 0s, but the
> Operation pseudo code below is correct. The same is true for SIDT.

I think the claim is that it fills with 0s when the software is
compatible with the 286, i.e. never uses a 32-bit LIDT or LGDT
instruction. Software written to target specifically older processors
typically used the undocumented LOADALL instruction to exit protected
mode or to set 4GB segment limits, so it won't run on QEMU. You can
read about the usage here:

https://www.os2museum.com/wp/more-on-loadall-and-os2/ (286)
https://www.os2museum.com/wp/386-loadall/ (386)

and about how it worked here:

https://www.pcjs.org/documents/manuals/intel/80286/loadall/
https://www.pcjs.org/documents/manuals/intel/80386/loadall/

Interestingly, byte 3 of the GDTR or IDTR on the 286 are documented as
"should be zeroes" for LOADALL, not all ones.

Let's change "Despite claims to the contrary" with "Despite a
confusing description".

Paolo

Re: [PATCH v3] hw/audio/virtio-snd: Use device endianness instead of target one

[Manos Pitsidianakis]

On Tue, 23 Apr 2024 at 11:47, Manos Pitsidianakis
 wrote:
>
> On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin  wrote:
> >
> > On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 22/4/24 23:02, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> > > > > Since VirtIO devices can change endianness at runtime,
> > > > > we need to use the device endianness, not the target
> > > > > one.
> > > > >
> > > > > Cc: qemu-sta...@nongnu.org
> > > > > Fixes: eb9ad377bb ("virtio-sound: handle control messages and 
> > > > > streams")
> > > > > Signed-off-by: Philippe Mathieu-Daudé 
> > > >
> > > >
> > > >
> > > > This is all completely bogus. Virtio SND is from Virtio 1.0 only.
> > > > It is unconditionally little endian.
>
>
> This part of the code is for PCM frames (raw bytes), not virtio spec
> fields (which indeed must be LE in modern VIRTIO).

Thought a little more about it. We should keep the target's endianness
here, if it's mutable then we should query the machine the device is
attached to somehow. the virtio device should never change endianness
like Michael says since it's not legacy.

Re: [PATCH v2 02/22] target/arm: Add confidential guest support

[Jean-Philippe Brucker]

On Fri, Apr 19, 2024 at 05:25:12PM +0100, Daniel P. Berrangé wrote:
> On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
> > Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
> > support the Arm Realm Management Extension (RME). It is instantiated by
> > passing on the command-line:
> > 
> >   -M virt,confidential-guest-support=
> >   -object guest-rme,id=[,options...]

Hm, the commit message is wrong, it should say "rme-guest".

> How about either "arm-rme" or merely 'rme' as the object name 

I don't feel strongly about the name, but picked this one to be consistent
with existing confidential-guest-support objects: sev-guest, pef-guest,
s390-pv-guest, and upcoming tdx-guest [1]

Thanks,
Jean

[1] 
https://lore.kernel.org/qemu-devel/20240229063726.610065-13-xiaoyao...@intel.com/

Re: [PATCH v2 02/22] target/arm: Add confidential guest support

[Daniel P . Berrangé]

On Tue, Apr 23, 2024 at 10:44:56AM +0100, Jean-Philippe Brucker wrote:
> On Fri, Apr 19, 2024 at 05:25:12PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
> > > Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
> > > support the Arm Realm Management Extension (RME). It is instantiated by
> > > passing on the command-line:
> > > 
> > >   -M virt,confidential-guest-support=
> > >   -object guest-rme,id=[,options...]
> 
> Hm, the commit message is wrong, it should say "rme-guest".
> 
> > How about either "arm-rme" or merely 'rme' as the object name 
> 
> I don't feel strongly about the name, but picked this one to be consistent
> with existing confidential-guest-support objects: sev-guest, pef-guest,
> s390-pv-guest, and upcoming tdx-guest [1]

Lets stick with 'rme-guest' then.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH RFC] prevent overflow in xlnx_dpdma_desc_get_source_address()

[Alexandra Diupina]

17/04/24 13:05, Konrad, Frederic пишет:

Hi,


-Original Message-
From: qemu-devel-bounces+fkonrad=amd@nongnu.org 
 On Behalf Of
Peter Maydell
Sent: Friday, April 12, 2024 12:07 PM
To: Alexandra Diupina 
Cc: Alistair Francis ; Edgar E. Iglesias 
; qemu-...@nongnu.org; qemu-
de...@nongnu.org; sdl.q...@linuxtesting.org
Subject: Re: [PATCH RFC] prevent overflow in 
xlnx_dpdma_desc_get_source_address()

On Fri, 12 Apr 2024 at 09:13, Alexandra Diupina  wrote:

Overflow can occur in a situation where desc->source_address
has a maximum value (pow(2, 32) - 1), so add a cast to a
larger type before the assignment.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: d3c6369a96 ("introduce xlnx-dpdma")
Signed-off-by: Alexandra Diupina 
---
  hw/dma/xlnx_dpdma.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/dma/xlnx_dpdma.c b/hw/dma/xlnx_dpdma.c
index 1f5cd64ed1..224259225c 100644
--- a/hw/dma/xlnx_dpdma.c
+++ b/hw/dma/xlnx_dpdma.c
@@ -175,24 +175,24 @@ static uint64_t 
xlnx_dpdma_desc_get_source_address(DPDMADescriptor *desc,

  switch (frag) {
  case 0:
-addr = desc->source_address
-+ (extract32(desc->address_extension, 16, 12) << 20);
+addr = (uint64_t)(desc->source_address
++ (extract32(desc->address_extension, 16, 12) << 20));

Unless I'm confused, this cast doesn't help, because we
will have already done a 32-bit addition of desc->source_address
and the value from the address_extension part, so it doesn't
change the result.

If we want to do the addition at 64 bits then using extract64()
would be the simplest way to arrange for that.

However, I can't figure out what this code is trying to do and
make that line up with the data sheet; maybe this isn't the
right datasheet for this device?

https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field

The datasheet suggests that we should take 32 bits of the address
from one field (here desc->source_address) and 16 bits of the
address from another (here desc->address_extension's high bits)
and combine them to make a 48 bit address. But this code is only
looking at 12 bits of the high 16 in address_extension, and it
doesn't shift them right enough to put them into bits [47:32]
of the final address.

Xilinx folks: what hardware is this modelling, and is it
really the right behaviour?

Looks like this is the right documentation.  Most probably the descriptor field 
changed
since I did that model, or I got really confused.


Also, this device looks like it has a host-endianness bug: the
DPDMADescriptor struct is read directly from guest memory in
dma_memory_read(), but the device never does anything to swap
the fields from guest memory order to host memory order. So
this is likely broken on big-endian hosts.


Yes indeed.

Best Regards,
Fred


thanks
-- PMM


hw/dma/xlnx_dpdma.c defines a dma_ops structure
with the endianness field set to DEVICE_NATIVE_ENDIAN.
Doesn't this guarantee that there will be no endian errors?

Alexandra

Re: [PATCH 0/6] Add ivshmem-flat device

[Markus Armbruster]

Gustavo Romero  writes:

> Hi Markus,
>
> Thanks for interesting in the ivshmem-flat device.
>
> Bill Mills (cc:ed) is the best person to answer your question,
> so please find his answer below.
>
> On 2/28/24 3:29 AM, Markus Armbruster wrote:
>> Gustavo Romero  writes:
>> 
>> [...]
>> 
>>> This patchset introduces a new device, ivshmem-flat, which is similar to the
>>> current ivshmem device but does not require a PCI bus. It implements the 
>>> ivshmem
>>> status and control registers as MMRs and the shared memory as a directly
>>> accessible memory region in the VM memory layout. It's meant to be used on
>>> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
>>> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a 
>>> tiny
>>> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
>>> memory-constrained resource targets.
>>>
>>> The patchset includes a QTest for the ivshmem-flat device, however, it's 
>>> also
>>> possible to experiment with it in two ways:
>>>
>>> (a) using two Cortex-M VMs running Zephyr; or
>>> (b) using one aarch64 VM running Linux with the ivshmem PCI device and 
>>> another
>>>  arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>>>
>>> Please note that for running the ivshmem-flat QTests the following patch, 
>>> which
>>> is not committed to the tree yet, must be applied:
>>>
>>> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
>> 
>> What problem are you trying to solve with ivshmem?
>> 
>> Shared memory is not a solution to any communication problem, it's
>> merely a building block for building such solutions: you invariably have
>> to layer some protocol on top.  What do you intend to put on top of
>> ivshmem?
>
> Actually ivshmem is shared memory and bi-direction notifications (in this 
> case a doorbell register and an irq).

Yes, ivshmem-doorbell supports interrupts.  Doesn't change my argument.

> This is the fundamental requirement for many types of communication but our 
> interest is for the OpenAMP project [1].
>
> All the OpenAMP project's communication is based on shared memory and 
> bi-directional notification.  Often this is on a AMP SOC with Cortex-As and 
> Cortex-Ms or Rs.  However we are now expanding into PCIe based AMP. One 
> example of this is an x86 host computer and a PCIe card with an ARM SOC.  
> Other examples include two systems with PCIe root complex connected via a 
> non-transparent bridge.
>
> The existing PCI based ivshmem lets us model these types of systems in a 
> simple generic way without worrying about the details of the RC/EP 
> relationship or the details of a specific non-transparent bridge.  In fact 
> the ivshmem looks to the two (or more) systems like a non-transparent bridge 
> with its own memory (and no other memory access is allowed).
>
> Right now we are testing this with RPMSG between two QEMU system where both 
> systems are cortex-a53 and both running Zephyr. [2]
>
> We will expand this by switching one of the QEMU systems to either arm64 
> Linux or x86 Linux.

So you want to simulate a heterogeneous machine by connecting multiple
qemu-system-FOO processes via ivshmem, correct?

> We (and others) are also working on a generic virtio transport that will work 
> between any two systems as long as they have shared memory and bi-directional 
> notifications.

On top of or adjacent to ivshmem?

> Now for ivshmem-flat.  We want to expand this model to include MCU like CPUs 
> and RTOS'es that don't have PCIe.  We focus on Cortex-M because every open 
> source RTOS has an existing port for one of the Cortex-M machines already in 
> QEMU.  However they don't normally pick the same one.  If we added our own 
> custom machine for this, the QEMU project would push back and even if 
> accepted we would have to do a port for each RTOS.  This would mean we would 
> not test as many RTOSes.
>
> The ivshmem-flat is actually a good model for what a Cortex-M based PCIe card 
> would look like.  The host system would see the connection as PCIe but to the 
> Cortex-M it would just appear as memory, MMR's for the doorbell, and an IRQ.
>
> So even after we have a "roll your own machine definition from a file", I 
> expect ivshmem and ivshmem-flat to still be very useful.
>
> [1] https://www.openampproject.org/
> [2] Work in progress here: 
> https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/zephyr/dual_qemu_ivshmem

Re: [PATCH RFC] prevent overflow in xlnx_dpdma_desc_get_source_address()

[Peter Maydell]

On Tue, 23 Apr 2024 at 11:23, Alexandra Diupina  wrote:
> 17/04/24 13:05, Konrad, Frederic пишет:
> > Peter Maydell wrote:
> >> Also, this device looks like it has a host-endianness bug: the
> >> DPDMADescriptor struct is read directly from guest memory in
> >> dma_memory_read(), but the device never does anything to swap
> >> the fields from guest memory order to host memory order. So
> >> this is likely broken on big-endian hosts.

> hw/dma/xlnx_dpdma.c defines a dma_ops structure
> with the endianness field set to DEVICE_NATIVE_ENDIAN.
> Doesn't this guarantee that there will be no endian errors?

The endianness on a MemoryRegionOps struct tells the
memory core how to handle guest accesses to the
*registers* that struct is for. So if the .endianness
is DEVICE_LITTLE_ENDIAN and the guest is big-endian,
the memory core will byteswap the data values. That
means that the read and write functions always take
and return "value" arguments which are what you expect
(i.e. the guest wrote 0x12345678 and the write fn
value argument is 0x12345678).

However, if a device does direct accesses to guest *memory* (like
a DMA-capable device will do), that is something it has to handle
the endianness for itself. (The device's manual should say what
way round it does memory loads.)
There are two basic ways a device can do guest memory access:

 (1) we provide functions which say "load from guest memory
 a value of this type with this endianness"; for instance
 ldq_le_dma() will load a 64-bit little-endian value into a
 host C uint64_t, and ldq_be_dma() will do the same for a 64-bit
 big-endian value. There are similar functions for stores.
 This can be the simplest approach but it's a bit less efficient
 because it goes up and down the memory subsystem for each data
 item being read.

 (2) we provide functions which are "load/store a sequence of bytes
 from guest memory". This is what dma_memory_read() does.
 Because it's just a sequence of bytes, the device code is
 then responsible for interpreting what those bytes mean:
 maybe they're just bytes, or maybe they're a sequence of
 little-endian 32-bit values, or maybe they're something else.
 The device code also has to deal with the fact that the
 alignment of these values in memory is not necessarily the
 same as what the host CPU requires. These things together
 mean you can't simply cast the pointer to a sequence-of-bytes
 to a host type, or tell dma_memory_read() to write the
 sequence-of-bytes to a host struct type. We provide functions
 like ldl_le_p() to say "read a little-endian 32-bit value
 from this host pointer location" to assist in pulling
 values out of a sequence-of-bytes array. Or if the data is
 all of the same type (eg it's an array of 32-bit values)
 you can dma_memory_read() it into a host uint32_t[] array
 and then use le32_to_cpu() to convert those uint32_t values
 to the host's endianness.

(I use the dma_* family of functions here as an example since that's
what xlnx_dpdma.c happens to use; the same general principle applies
for our various other families of guest load/store functions, like
the address_space_* ones.)

thanks
-- PMM

Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support

[Markus Armbruster]

Jonathan Cameron  writes:

> These are very similar to the recently added Generic Initiators
> but instead of representing an initiator of memory traffic they
> represent an edge point beyond which may lie either targets or
> initiators.  Here we add these ports such that they may
> be targets of hmat_lb records to describe the latency and
> bandwidth from host side initiators to the port.  A descoverable
> mechanism such as UEFI CDAT read from CXL devices and switches
> is used to discover the remainder fo the path and the OS can build
> up full latency and bandwidth numbers as need for work and data
> placement decisions.
>
> Signed-off-by: Jonathan Cameron 
> ---
>  qapi/qom.json|  18 +++
>  include/hw/acpi/acpi_generic_initiator.h |  18 ++-
>  include/hw/pci/pci_bridge.h  |   1 +
>  hw/acpi/acpi_generic_initiator.c | 141 +--
>  hw/pci-bridge/pci_expander_bridge.c  |   1 -
>  5 files changed, 141 insertions(+), 38 deletions(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 85e6b4f84a..5480d9ca24 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -826,6 +826,22 @@
>'data': { 'pci-dev': 'str',
>  'node': 'uint32' } }
>  
> +
> +##
> +# @AcpiGenericPortProperties:
> +#
> +# Properties for acpi-generic-port objects.
> +#
> +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry

What's this exactly?  A QOM path?  A qdev ID?  Something else?

> +#
> +# @node: numa node associated with the PCI device

NUMA

Is this a NUMA node ID?

> +#
> +# Since: 9.1
> +##
> +{ 'struct': 'AcpiGenericPortProperties',
> +  'data': { 'pci-bus': 'str',
> +'node': 'uint32' } }
> +
>  ##
>  # @RngProperties:
>  #
> @@ -944,6 +960,7 @@
>  { 'enum': 'ObjectType',
>'data': [
>  'acpi-generic-initiator',
> +'acpi-generic-port',
>  'authz-list',
>  'authz-listfile',
>  'authz-pam',
> @@ -1016,6 +1033,7 @@
>'discriminator': 'qom-type',
>'data': {
>'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> +  'acpi-generic-port':  'AcpiGenericPortProperties',
>'authz-list': 'AuthZListProperties',
>'authz-listfile': 'AuthZListFileProperties',
>'authz-pam':  'AuthZPAMProperties',

[...]

Re: [PATCH v3] hw/audio/virtio-snd: Use device endianness instead of target one

[Philippe Mathieu-Daudé]

On 23/4/24 11:18, Manos Pitsidianakis wrote:

On Tue, 23 Apr 2024 at 11:47, Manos Pitsidianakis
 wrote:


On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin  wrote:


On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:

On 22/4/24 23:02, Michael S. Tsirkin wrote:

On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:

Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.

Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
Signed-off-by: Philippe Mathieu-Daudé 




This is all completely bogus. Virtio SND is from Virtio 1.0 only.
It is unconditionally little endian.



This part of the code is for PCM frames (raw bytes), not virtio spec
fields (which indeed must be LE in modern VIRTIO).


Thought a little more about it. We should keep the target's endianness
here, if it's mutable then we should query the machine the device is
attached to somehow. the virtio device should never change endianness
like Michael says since it's not legacy.


Grr. So as Richard suggested, this need to be pass as a device
property then.
(https://lore.kernel.org/qemu-devel/ed134c9d-6e6f-465b-900f-e39ca4e09...@linaro.org/)

Re: [PATCH 2/3] target/arm: Refactor default generic timer frequency handling

[Philippe Mathieu-Daudé]

On 19/4/24 20:46, Peter Maydell wrote:

The generic timer frequency is settable by board code via a QOM
property "cntfrq", but otherwise defaults to 62.5MHz.  The way this
is done includes some complication resulting from how this was
originally a fixed value with no QOM property.  Clean it up:

  * always set cpu->gt_cntfrq_hz to some sensible value, whether
the CPU has the generic timer or not, and whether it's system
or user-only emulation
  * this means we can always use gt_cntfrq_hz, and never need
the old GTIMER_SCALE define
  * set the default value in exactly one place, in the realize fn

The aim here is to pave the way for handling the ARMv8.6 requirement
that the generic timer frequency is always 1GHz.  We're going to do
that by having old CPU types keep their legacy-in-QEMU behaviour and
having the default for any new CPU types be a 1GHz rather han 62.5MHz
cntfrq, so we want the point where the default is decided to be in
one place, and in code, not in a DEFINE_PROP_UINT64() initializer.

This commit should have no behavioural changes.

Signed-off-by: Peter Maydell 
---
  target/arm/internals.h |  7 ---
  target/arm/cpu.c   | 31 +--
  target/arm/helper.c| 16 
  3 files changed, 29 insertions(+), 25 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v2 02/22] target/arm: Add confidential guest support

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
>> Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
>> support the Arm Realm Management Extension (RME). It is instantiated by
>> passing on the command-line:
>> 
>>   -M virt,confidential-guest-support=
>>   -object guest-rme,id=[,options...]

rme-guest

Since there are no options so far, I'd omit [,options...]

> How about either "arm-rme" or merely 'rme' as the object name 

"arm-rme" sounds good to me.  Need to adjust the various identifiers
with "guest" in them, then.

>> This is only the skeleton. Support will be added in following patches.
>> 
>> Cc: Eric Blake 
>> Cc: Markus Armbruster 
>> Cc: Daniel P. Berrangé 
>> Cc: Eduardo Habkost 
>> Reviewed-by: Philippe Mathieu-Daudé 
>> Reviewed-by: Richard Henderson 
>> Signed-off-by: Jean-Philippe Brucker 

QAPI schema
Acked-by: Markus Armbruster 

Re: [PATCH v2 14/22] target/arm/kvm-rme: Add Realm Personalization Value parameter

[Markus Armbruster]

Jean-Philippe Brucker  writes:

> The Realm Personalization Value (RPV) is provided by the user to
> distinguish Realms that have the same initial measurement.
>
> The user provides up to 64 hexadecimal bytes. They are stored into the
> RPV in the same order, zero-padded on the right.
>
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Daniel P. Berrangé 
> Cc: Eduardo Habkost 
> Signed-off-by: Jean-Philippe Brucker 
> ---
> v1->v2: Move parsing early, store as-is rather than reverted
> ---
>  qapi/qom.json|  15 +-
>  target/arm/kvm-rme.c | 111 +++
>  2 files changed, 125 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 623ec8071f..91654aa267 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -931,6 +931,18 @@
>'data': { '*cpu-affinity': ['uint16'],
>  '*node-affinity': ['uint16'] } }
>  
> +##
> +# @RmeGuestProperties:
> +#
> +# Properties for rme-guest objects.
> +#
> +# @personalization-value: Realm personalization value, as a 64-byte hex 
> string
> +# (default: 0)

docs/devel/qapi-code-gen.rst:

For legibility, wrap text paragraphs so every line is at most 70
characters long.

> +#
> +# Since: FIXME

9.1

> +##
> +{ 'struct': 'RmeGuestProperties',
> +  'data': { '*personalization-value': 'str' } }
>  
>  ##
>  # @ObjectType:
> @@ -1066,7 +1078,8 @@
>'tls-creds-x509': 'TlsCredsX509Properties',
>'tls-cipher-suites':  'TlsCredsProperties',
>'x-remote-object':'RemoteObjectProperties',
> -  'x-vfio-user-server': 'VfioUserServerProperties'
> +  'x-vfio-user-server': 'VfioUserServerProperties',
> +  'rme-guest':  'RmeGuestProperties'
>} }
>  
>  ##

With the doc comment issues addressed, QAPI schema
Acked-by: Markus Armbruster 

[...]

Re: [PATCH v2 14/22] target/arm/kvm-rme: Add Realm Personalization Value parameter

[Peter Maydell]

On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
 wrote:
>
> The Realm Personalization Value (RPV) is provided by the user to
> distinguish Realms that have the same initial measurement.
>
> The user provides up to 64 hexadecimal bytes. They are stored into the
> RPV in the same order, zero-padded on the right.
>
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Daniel P. Berrangé 
> Cc: Eduardo Habkost 
> Signed-off-by: Jean-Philippe Brucker 
> ---
> v1->v2: Move parsing early, store as-is rather than reverted
> ---
>  qapi/qom.json|  15 +-
>  target/arm/kvm-rme.c | 111 +++
>  2 files changed, 125 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 623ec8071f..91654aa267 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -931,6 +931,18 @@
>'data': { '*cpu-affinity': ['uint16'],
>  '*node-affinity': ['uint16'] } }
>
> +##
> +# @RmeGuestProperties:
> +#
> +# Properties for rme-guest objects.
> +#
> +# @personalization-value: Realm personalization value, as a 64-byte hex 
> string
> +# (default: 0)
> +#
> +# Since: FIXME
> +##
> +{ 'struct': 'RmeGuestProperties',
> +  'data': { '*personalization-value': 'str' } }
>
>  ##
>  # @ObjectType:
> @@ -1066,7 +1078,8 @@
>'tls-creds-x509': 'TlsCredsX509Properties',
>'tls-cipher-suites':  'TlsCredsProperties',
>'x-remote-object':'RemoteObjectProperties',
> -  'x-vfio-user-server': 'VfioUserServerProperties'
> +  'x-vfio-user-server': 'VfioUserServerProperties',
> +  'rme-guest':  'RmeGuestProperties'
>} }

This list is in alphabetical order. Are we obliged to add new
items to the end for some compatibility reason, or should this new
item be filed in its correct place with the other 'r's ?

thanks
-- PMM

Re: [PATCH v2 15/22] target/arm/kvm-rme: Add measurement algorithm property

[Markus Armbruster]

Jean-Philippe Brucker  writes:

> This option selects which measurement algorithm to use for attestation.
> Supported values are SHA256 and SHA512. Default to SHA512 arbitrarily.
>
> SHA512 is generally faster on 64-bit architectures. On a few arm64 CPUs
> I tested SHA256 is much faster, but that's most likely because they only
> support acceleration via FEAT_SHA256 (Armv8.0) and not FEAT_SHA512
> (Armv8.2). Future CPUs supporting RME are likely to also support
> FEAT_SHA512.
>
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Daniel P. Berrangé 
> Cc: Eduardo Habkost 
> Signed-off-by: Jean-Philippe Brucker 
> ---
> v1->v2: use enum, pick default
> ---
>  qapi/qom.json| 18 +-
>  target/arm/kvm-rme.c | 39 ++-
>  2 files changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 91654aa267..84dce666b2 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -931,18 +931,34 @@
>'data': { '*cpu-affinity': ['uint16'],
>  '*node-affinity': ['uint16'] } }
>  
> +##
> +# @RmeGuestMeasurementAlgo:
> +#
> +# @sha256: Use the SHA256 algorithm

Let's have a blank line here.

> +# @sha512: Use the SHA512 algorithm
> +#
> +# Algorithm to use for realm measurements
> +#
> +# Since: FIXME

9.1

> +##
> +{ 'enum': 'RmeGuestMeasurementAlgo',
> +  'data': ['sha256', 'sha512'] }
> +
>  ##
>  # @RmeGuestProperties:
>  #
>  # Properties for rme-guest objects.
>  #
> +# @measurement-algo: Realm measurement algorithm (default: sha512)
> +#

We tend to avoid abbreviations in QMP: @measurement-algorithm.

May want to rename the type to RmeGuestMeasurementAlgorithm for
consistency.

>  # @personalization-value: Realm personalization value, as a 64-byte hex 
> string
>  # (default: 0)
>  #
>  # Since: FIXME
>  ##
>  { 'struct': 'RmeGuestProperties',
> -  'data': { '*personalization-value': 'str' } }
> +  'data': { '*personalization-value': 'str',
> +'*measurement-algo': 'RmeGuestMeasurementAlgo' } }
>  
>  ##
>  # @ObjectType:

With these issues addressed, QAPI schema
Acked-by: Markus Armbruster 

[...]

Re: [PATCH v2 14/22] target/arm/kvm-rme: Add Realm Personalization Value parameter

[Daniel P . Berrangé]

On Tue, Apr 23, 2024 at 01:20:20PM +0100, Peter Maydell wrote:
> On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
>  wrote:
> >
> > The Realm Personalization Value (RPV) is provided by the user to
> > distinguish Realms that have the same initial measurement.
> >
> > The user provides up to 64 hexadecimal bytes. They are stored into the
> > RPV in the same order, zero-padded on the right.
> >
> > Cc: Eric Blake 
> > Cc: Markus Armbruster 
> > Cc: Daniel P. Berrangé 
> > Cc: Eduardo Habkost 
> > Signed-off-by: Jean-Philippe Brucker 
> > ---
> > v1->v2: Move parsing early, store as-is rather than reverted
> > ---
> >  qapi/qom.json|  15 +-
> >  target/arm/kvm-rme.c | 111 +++
> >  2 files changed, 125 insertions(+), 1 deletion(-)
> >
> > diff --git a/qapi/qom.json b/qapi/qom.json
> > index 623ec8071f..91654aa267 100644
> > --- a/qapi/qom.json
> > +++ b/qapi/qom.json
> > @@ -931,6 +931,18 @@
> >'data': { '*cpu-affinity': ['uint16'],
> >  '*node-affinity': ['uint16'] } }
> >
> > +##
> > +# @RmeGuestProperties:
> > +#
> > +# Properties for rme-guest objects.
> > +#
> > +# @personalization-value: Realm personalization value, as a 64-byte hex 
> > string
> > +# (default: 0)
> > +#
> > +# Since: FIXME
> > +##
> > +{ 'struct': 'RmeGuestProperties',
> > +  'data': { '*personalization-value': 'str' } }
> >
> >  ##
> >  # @ObjectType:
> > @@ -1066,7 +1078,8 @@
> >'tls-creds-x509': 'TlsCredsX509Properties',
> >'tls-cipher-suites':  'TlsCredsProperties',
> >'x-remote-object':'RemoteObjectProperties',
> > -  'x-vfio-user-server': 'VfioUserServerProperties'
> > +  'x-vfio-user-server': 'VfioUserServerProperties',
> > +  'rme-guest':  'RmeGuestProperties'
> >} }
> 
> This list is in alphabetical order. Are we obliged to add new
> items to the end for some compatibility reason, or should this new
> item be filed in its correct place with the other 'r's ?

Ordering has no bearing on compatibility, so this should be at the
correct alphbetical position.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH v2 14/22] target/arm/kvm-rme: Add Realm Personalization Value parameter

[Markus Armbruster]

Peter Maydell  writes:

> On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
>  wrote:
>>
>> The Realm Personalization Value (RPV) is provided by the user to
>> distinguish Realms that have the same initial measurement.
>>
>> The user provides up to 64 hexadecimal bytes. They are stored into the
>> RPV in the same order, zero-padded on the right.
>>
>> Cc: Eric Blake 
>> Cc: Markus Armbruster 
>> Cc: Daniel P. Berrangé 
>> Cc: Eduardo Habkost 
>> Signed-off-by: Jean-Philippe Brucker 
>> ---
>> v1->v2: Move parsing early, store as-is rather than reverted
>> ---
>>  qapi/qom.json|  15 +-
>>  target/arm/kvm-rme.c | 111 +++
>>  2 files changed, 125 insertions(+), 1 deletion(-)
>>
>> diff --git a/qapi/qom.json b/qapi/qom.json
>> index 623ec8071f..91654aa267 100644
>> --- a/qapi/qom.json
>> +++ b/qapi/qom.json
>> @@ -931,6 +931,18 @@
>>'data': { '*cpu-affinity': ['uint16'],
>>  '*node-affinity': ['uint16'] } }
>>
>> +##
>> +# @RmeGuestProperties:
>> +#
>> +# Properties for rme-guest objects.
>> +#
>> +# @personalization-value: Realm personalization value, as a 64-byte hex 
>> string
>> +# (default: 0)
>> +#
>> +# Since: FIXME
>> +##
>> +{ 'struct': 'RmeGuestProperties',
>> +  'data': { '*personalization-value': 'str' } }
>>
>>  ##
>>  # @ObjectType:
>> @@ -1066,7 +1078,8 @@
>>'tls-creds-x509': 'TlsCredsX509Properties',
>>'tls-cipher-suites':  'TlsCredsProperties',
>>'x-remote-object':'RemoteObjectProperties',
>> -  'x-vfio-user-server': 'VfioUserServerProperties'
>> +  'x-vfio-user-server': 'VfioUserServerProperties',
>> +  'rme-guest':  'RmeGuestProperties'
>>} }
>
> This list is in alphabetical order. Are we obliged to add new
> items to the end for some compatibility reason, or should this new

Since order does not matter, we should keep it sorted.  Same for enum
ObjectType.

Thanks!

Re: [PATCH] target/riscv: change RISCV_EXCP_SEMIHOST exception number to 63

[Clément Léger]

On 22/04/2024 21:58, Daniel Henrique Barboza wrote:
> 
> 
> On 4/22/24 16:44, Richard Henderson wrote:
>> On 4/22/24 10:45, Daniel Henrique Barboza wrote:
>>> Palmer, Anup,
>>>
>>> On 4/22/24 10:58, Clément Léger wrote:
 The current semihost exception number (16) is a reserved number (range
 [16-17]). The upcoming double trap specification uses that number for
 the double trap exception. Since the privileged spec (Table 22) defines
 ranges for custom uses change the semihosting exception number to 63
 which belongs to the range [48-63] in order to avoid any future
 collisions with reserved exception.
>>>
>>>
>>> I didn't find any reference to a number for the SEMIHOST exception here:
>>>
>>>
>>> https://github.com/riscv-non-isa/riscv-semihosting
>>>
>>>
>>> Do we have any potential candidates? I would like to avoid, if
>>> possible, setting
>>> RISCV_EXCP_SEMIHOST to 63 as a band-aid just to replace it later on
>>> by the real
>>> value.
>>
>> RISCV_EXCP_SEMIHOST is internal to the qemu implementation and will
>> never be delivered to the guest.
>>
>> I suggest using a number high in the >64 reserved range which will
>> (likely) never be used by any implementation, including ones that *do*
>> define implementation-specific exceptions.  Which seems more likely
>> than not within the "implementation defined" range.
>>
>> E.g. target/i386 uses 0x100+n for qemu internal exceptions.
> 
> I'm not sure if we have a range for risc-v qemu internal exceptions
> only. IIRC we don't.
> 
> If that's really the case I believe we could use whatever i386/ARM uses.
> At least we'll have some
> standardization.

The spec also states that numbers >= 64 are reserved which is why using
a one for custom use was making sense.

Thanks,

Clément

> 
> 
> Thanks,
> 
> Daniel
> 
>>
>> But in any case, the number can be redefined at will and not cause
>> compatibility issues.
>>
>>
>> r~

[PATCH v2 1/1] migration/dirtyrate: Fix segmentation fault

[Masato Imai]

When the KVM acceleration parameter is not set, executing calc_dirty_rate
with the -r or -b option results in a segmentation fault due to accessing
a null kvm_state pointer in the kvm_dirty_ring_enabled function.
This commit adds a check for kvm_enabled to prevent segmentation faults.

Signed-off-by: Masato Imai 
---
 migration/dirtyrate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 1d2e85746f..2a7df52519 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -799,6 +799,13 @@ void qmp_calc_dirty_rate(int64_t calc_time,
  * dirty ring mode only works when kvm dirty ring is enabled.
  * on the contrary, dirty bitmap mode is not.
  */
+if (!kvm_enabled() &&
+(mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING ||
+ mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP)) {
+error_setg(errp, "mode %s requires kvm to be enabled.",
+ DirtyRateMeasureMode_str(mode));
+return;
+}
 if (((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&
 !kvm_dirty_ring_enabled()) ||
 ((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP) &&
-- 
2.34.1

[PATCH] migration/dirtyrate: Fix segmentation fault

[Masato Imai]

When the KVM acceleration parameter is not set, executing calc_dirty_rate
with the -r option results in a segmentation fault due to accessing a
null kvm_state pointer in the kvm_dirty_rate_enabled function.
This commit adds a check for kvm_enabled to prevent segmentation faults.

Signed-off-by: Masato Imai 
---
 migration/dirtyrate.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 1d2e85746f..4c1579c6e9 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -800,6 +800,8 @@ void qmp_calc_dirty_rate(int64_t calc_time,
  * on the contrary, dirty bitmap mode is not.
  */
 if (((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&
+!kvm_enabled()) ||
+((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&
 !kvm_dirty_ring_enabled()) ||
 ((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP) &&
  kvm_dirty_ring_enabled())) {
-- 
2.34.1

[PATCH v2 0/1] migration/dirtyrate: Fix segmentation fault

[Masato Imai]

Changes from v1:
- fix typo in commit message
- added an extra check for dirty bitmap mode

Masato Imai (1):
  migration/dirtyrate: Fix segmentation fault

 migration/dirtyrate.c | 7 +++
 1 file changed, 7 insertions(+)

-- 
2.34.1

[PATCH 03/22] arm: switch boards to "default y"

[Paolo Bonzini]

For ARM targets, boards that require TCG are already using "default y".
Switch ARM_VIRT to the same selection mechanism.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/arm-softmmu/default.mak | 3 ++-
 hw/arm/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/devices/arm-softmmu/default.mak 
b/configs/devices/arm-softmmu/default.mak
index c1cfb3bcf75..31f77c20269 100644
--- a/configs/devices/arm-softmmu/default.mak
+++ b/configs/devices/arm-softmmu/default.mak
@@ -5,7 +5,8 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-CONFIG_ARM_VIRT=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_ARM_VIRT=n
 
 # These are selected by default when TCG is enabled, uncomment them to
 # keep out of the build.
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 893a7bff66b..1e7cd01087f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -1,5 +1,7 @@
 config ARM_VIRT
 bool
+default y
+depends on ARM
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply VFIO_AMD_XGBE
-- 
2.44.0

[PATCH 00/22] configs: switch boards to "default y"

[Paolo Bonzini]

Some boards, notably ARM boards that use TCG, are already using
"default y".  This was done to remove TCG-only boards from
a KVM-only build in commit 29d9efca16 (2023-04-26).

This series converts all other boards to that, so that the requirements
of each board are clearer in the Kconfig files.

For now, the only such use is MIPS's 64-bit and endianness requirements.
In the future, it will be possible to enable/disable boards based
on the presence of required libraries, for example libfdt, or
their deprecation status.

There is an important difference in that Kconfig symbols for boards
have to be enabled in a --without-default-devices build, similar to
devices.

Paolo

Paolo Bonzini (22):
  configs: list "implied" device groups in the default configs
  alpha: switch boards to "default y"
  arm: switch boards to "default y"
  avr: switch boards to "default y"
  cris: switch boards to "default y"
  hppa: switch boards to "default y"
  i386: switch boards to "default y"
  loongarch: switch boards to "default y"
  m68k: switch boards to "default y"
  microblaze: switch boards to "default y"
  meson: make target endianneess available to Kconfig
  mips: switch boards to "default y"
  nios2: switch boards to "default y"
  openrisc: switch boards to "default y"
  ppc: switch boards to "default y"
  riscv: switch boards to "default y"
  rx: switch boards to "default y"
  s390x: switch boards to "default y"
  sh4: switch boards to "default y"
  sparc: switch boards to "default y"
  tricore: switch boards to "default y"
  xtensa: switch boards to "default y"

 configs/devices/alpha-softmmu/default.mak |  5 ++--
 configs/devices/arm-softmmu/default.mak   |  5 +++-
 configs/devices/avr-softmmu/default.mak   |  5 ++--
 configs/devices/cris-softmmu/default.mak  |  5 ++--
 configs/devices/hppa-softmmu/default.mak  |  5 ++--
 configs/devices/i386-softmmu/default.mak  | 11 ---
 .../devices/loongarch64-softmmu/default.mak   |  6 +++-
 configs/devices/m68k-softmmu/default.mak  | 13 
 .../devices/microblaze-softmmu/default.mak|  9 +++---
 configs/devices/mips-softmmu/common.mak   |  5 ++--
 configs/devices/mips64-softmmu/default.mak|  4 ++-
 configs/devices/mips64el-softmmu/default.mak  | 10 ---
 configs/devices/nios2-softmmu/default.mak |  7 ++---
 configs/devices/or1k-softmmu/default.mak  |  9 --
 configs/devices/ppc-softmmu/default.mak   | 30 +++
 configs/devices/ppc64-softmmu/default.mak |  8 ++---
 configs/devices/riscv32-softmmu/default.mak   | 17 +--
 configs/devices/riscv64-softmmu/default.mak   | 19 ++--
 configs/devices/rx-softmmu/default.mak|  3 +-
 configs/devices/s390x-softmmu/default.mak |  5 ++--
 configs/devices/sh4-softmmu/default.mak   |  7 ++---
 configs/devices/sparc-softmmu/default.mak |  7 ++---
 configs/devices/sparc64-softmmu/default.mak   |  7 ++---
 configs/devices/tricore-softmmu/default.mak   |  7 +++--
 configs/devices/xtensa-softmmu/default.mak| 11 ---
 meson.build   | 12 
 hw/alpha/Kconfig  |  2 ++
 hw/arm/Kconfig|  2 ++
 hw/avr/Kconfig|  3 ++
 hw/cris/Kconfig   |  2 ++
 hw/hppa/Kconfig   |  2 ++
 hw/i386/Kconfig   | 10 ++-
 hw/loongarch/Kconfig  |  2 ++
 hw/m68k/Kconfig   | 10 +++
 hw/microblaze/Kconfig |  6 
 hw/mips/Kconfig   | 12 
 hw/nios2/Kconfig  |  9 +++---
 hw/openrisc/Kconfig   |  4 +++
 hw/ppc/Kconfig| 26 
 hw/riscv/Kconfig  | 14 +
 hw/rx/Kconfig |  2 ++
 hw/s390x/Kconfig  |  2 ++
 hw/sh4/Kconfig|  4 +++
 hw/sparc/Kconfig  |  4 +++
 hw/sparc64/Kconfig|  4 +++
 hw/tricore/Kconfig|  4 +++
 hw/xtensa/Kconfig |  6 
 target/Kconfig|  3 ++
 target/i386/Kconfig   |  1 +
 target/ppc/Kconfig|  1 +
 50 files changed, 252 insertions(+), 115 deletions(-)

-- 
2.44.0

[PATCH 06/22] hppa: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with PARISC.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/hppa-softmmu/default.mak | 5 ++---
 hw/hppa/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/devices/hppa-softmmu/default.mak 
b/configs/devices/hppa-softmmu/default.mak
index b0364bb88f2..059510cdbb7 100644
--- a/configs/devices/hppa-softmmu/default.mak
+++ b/configs/devices/hppa-softmmu/default.mak
@@ -4,6 +4,5 @@
 #
 #CONFIG_PCI_DEVICES=n
 
-# Boards:
-#
-CONFIG_HPPA_B160L=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_HPPA_B160L=n
diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index ee7ffd2bfb5..d4d457f4ab4 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -1,5 +1,7 @@
 config HPPA_B160L
 bool
+default y
+depends on HPPA
 imply PCI_DEVICES
 imply E1000_PCI
 imply USB_OHCI_PCI
-- 
2.44.0

[PATCH 02/22] alpha: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Start with Alpha.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/alpha-softmmu/default.mak | 5 ++---
 hw/alpha/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/devices/alpha-softmmu/default.mak 
b/configs/devices/alpha-softmmu/default.mak
index d186fe8e9b1..3de6a9f5779 100644
--- a/configs/devices/alpha-softmmu/default.mak
+++ b/configs/devices/alpha-softmmu/default.mak
@@ -5,6 +5,5 @@
 #CONFIG_PCI_DEVICES=n
 #CONFIG_TEST_DEVICES=n
 
-# Boards:
-#
-CONFIG_DP264=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_DP264=n
diff --git a/hw/alpha/Kconfig b/hw/alpha/Kconfig
index 9af650c94ec..7f3455ce1e1 100644
--- a/hw/alpha/Kconfig
+++ b/hw/alpha/Kconfig
@@ -1,5 +1,7 @@
 config DP264
 bool
+default y
+depends on ALPHA
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply E1000_PCI
-- 
2.44.0

[PATCH 01/22] configs: list "implied" device groups in the default configs

[Paolo Bonzini]

Match the optional device groups to what is actually included in
the config-devices.mak files.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/arm-softmmu/default.mak | 2 ++
 configs/devices/loongarch64-softmmu/default.mak | 3 +++
 configs/devices/or1k-softmmu/default.mak| 4 
 configs/devices/ppc-softmmu/default.mak | 4 
 configs/devices/riscv32-softmmu/default.mak | 4 ++--
 configs/devices/riscv64-softmmu/default.mak | 4 ++--
 configs/devices/xtensa-softmmu/default.mak  | 4 
 7 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/configs/devices/arm-softmmu/default.mak 
b/configs/devices/arm-softmmu/default.mak
index 6ee31bc1ab9..c1cfb3bcf75 100644
--- a/configs/devices/arm-softmmu/default.mak
+++ b/configs/devices/arm-softmmu/default.mak
@@ -1,5 +1,7 @@
 # Default configuration for arm-softmmu
 
+# Uncomment the following lines to disable these optional devices:
+# CONFIG_I2C_DEVICES=n
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
diff --git a/configs/devices/loongarch64-softmmu/default.mak 
b/configs/devices/loongarch64-softmmu/default.mak
index 928bc117ef7..0893112b81d 100644
--- a/configs/devices/loongarch64-softmmu/default.mak
+++ b/configs/devices/loongarch64-softmmu/default.mak
@@ -1,3 +1,6 @@
 # Default configuration for loongarch64-softmmu
 
+# Uncomment the following lines to disable these optional devices:
+# CONFIG_PCI_DEVICES=n
+
 CONFIG_LOONGARCH_VIRT=y
diff --git a/configs/devices/or1k-softmmu/default.mak 
b/configs/devices/or1k-softmmu/default.mak
index 89c39e31237..3aecdf9d738 100644
--- a/configs/devices/or1k-softmmu/default.mak
+++ b/configs/devices/or1k-softmmu/default.mak
@@ -1,5 +1,9 @@
 # Default configuration for or1k-softmmu
 
+# Uncomment the following lines to disable these optional devices:
+# CONFIG_PCI_DEVICES=n
+# CONFIG_TEST_DEVICES=n
+
 # Boards:
 #
 CONFIG_OR1K_SIM=y
diff --git a/configs/devices/ppc-softmmu/default.mak 
b/configs/devices/ppc-softmmu/default.mak
index b85fd2bcd71..3061b26749a 100644
--- a/configs/devices/ppc-softmmu/default.mak
+++ b/configs/devices/ppc-softmmu/default.mak
@@ -1,5 +1,9 @@
 # Default configuration for ppc-softmmu
 
+# Uncomment the following lines to disable these optional devices:
+# CONFIG_PCI_DEVICES=n
+# CONFIG_TEST_DEVICES=n
+
 # For embedded PPCs:
 CONFIG_E500PLAT=y
 CONFIG_MPC8544DS=y
diff --git a/configs/devices/riscv32-softmmu/default.mak 
b/configs/devices/riscv32-softmmu/default.mak
index 94a236c9c25..07e4fd26df3 100644
--- a/configs/devices/riscv32-softmmu/default.mak
+++ b/configs/devices/riscv32-softmmu/default.mak
@@ -1,8 +1,8 @@
 # Default configuration for riscv32-softmmu
 
 # Uncomment the following lines to disable these optional devices:
-#
-#CONFIG_PCI_DEVICES=n
+# CONFIG_PCI_DEVICES=n
+# CONFIG_TEST_DEVICES=n
 
 # Boards:
 #
diff --git a/configs/devices/riscv64-softmmu/default.mak 
b/configs/devices/riscv64-softmmu/default.mak
index 3f680594484..221963d4c5c 100644
--- a/configs/devices/riscv64-softmmu/default.mak
+++ b/configs/devices/riscv64-softmmu/default.mak
@@ -1,8 +1,8 @@
 # Default configuration for riscv64-softmmu
 
 # Uncomment the following lines to disable these optional devices:
-#
-#CONFIG_PCI_DEVICES=n
+# CONFIG_PCI_DEVICES=n
+# CONFIG_TEST_DEVICES=n
 
 # Boards:
 #
diff --git a/configs/devices/xtensa-softmmu/default.mak 
b/configs/devices/xtensa-softmmu/default.mak
index 49e4c9da88c..f650cad7609 100644
--- a/configs/devices/xtensa-softmmu/default.mak
+++ b/configs/devices/xtensa-softmmu/default.mak
@@ -1,5 +1,9 @@
 # Default configuration for Xtensa
 
+# Uncomment the following lines to disable these optional devices:
+#
+#CONFIG_PCI_DEVICES=n
+
 # Boards:
 #
 CONFIG_XTENSA_SIM=y
-- 
2.44.0

[PATCH 17/22] rx: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with RX.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/rx-softmmu/default.mak | 3 ++-
 hw/rx/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/devices/rx-softmmu/default.mak 
b/configs/devices/rx-softmmu/default.mak
index df2b4e4f426..e7caebe1974 100644
--- a/configs/devices/rx-softmmu/default.mak
+++ b/configs/devices/rx-softmmu/default.mak
@@ -1,3 +1,4 @@
 # Default configuration for rx-softmmu
 
-CONFIG_RX_GDBSIM=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_RX_GDBSIM=n
diff --git a/hw/rx/Kconfig b/hw/rx/Kconfig
index 2b297c5a6a6..b2fa2b7eec3 100644
--- a/hw/rx/Kconfig
+++ b/hw/rx/Kconfig
@@ -7,4 +7,6 @@ config RX62N_MCU
 
 config RX_GDBSIM
 bool
+default y
+depends on RX
 select RX62N_MCU
-- 
2.44.0

[PATCH 12/22] mips: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with MIPS.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/mips-softmmu/common.mak  |  5 +++--
 configs/devices/mips64-softmmu/default.mak   |  4 +++-
 configs/devices/mips64el-softmmu/default.mak | 10 ++
 hw/mips/Kconfig  | 12 
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/configs/devices/mips-softmmu/common.mak 
b/configs/devices/mips-softmmu/common.mak
index 416a5d353e8..b50107feafe 100644
--- a/configs/devices/mips-softmmu/common.mak
+++ b/configs/devices/mips-softmmu/common.mak
@@ -4,5 +4,6 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-CONFIG_MALTA=y
-CONFIG_MIPSSIM=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_MALTA=n
+# CONFIG_MIPSSIM=n
diff --git a/configs/devices/mips64-softmmu/default.mak 
b/configs/devices/mips64-softmmu/default.mak
index 566672f3c22..1b8d7ced1c6 100644
--- a/configs/devices/mips64-softmmu/default.mak
+++ b/configs/devices/mips64-softmmu/default.mak
@@ -1,4 +1,6 @@
 # Default configuration for mips64-softmmu
 
 include ../mips-softmmu/common.mak
-CONFIG_JAZZ=y
+
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_JAZZ=n
diff --git a/configs/devices/mips64el-softmmu/default.mak 
b/configs/devices/mips64el-softmmu/default.mak
index 88a37cf27f1..9dce346c4fb 100644
--- a/configs/devices/mips64el-softmmu/default.mak
+++ b/configs/devices/mips64el-softmmu/default.mak
@@ -1,7 +1,9 @@
 # Default configuration for mips64el-softmmu
 
 include ../mips-softmmu/common.mak
-CONFIG_FULOONG=y
-CONFIG_LOONGSON3V=y
-CONFIG_JAZZ=y
-CONFIG_MIPS_BOSTON=y
+
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_FULOONG=n
+# CONFIG_LOONGSON3V=n
+# CONFIG_JAZZ=n
+# CONFIG_MIPS_BOSTON=n
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index 5c83ef49cf6..9bccb363eb9 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -1,5 +1,7 @@
 config MALTA
 bool
+default y
+depends on MIPS
 imply PCNET_PCI
 imply PCI_DEVICES
 imply TEST_DEVICES
@@ -13,11 +15,15 @@ config MALTA
 
 config MIPSSIM
 bool
+default y
+depends on MIPS
 select SERIAL
 select MIPSNET
 
 config JAZZ
 bool
+default y
+depends on MIPS64
 select ISA_BUS
 select RC4030
 select I8259
@@ -38,6 +44,8 @@ config JAZZ
 
 config FULOONG
 bool
+default y
+depends on MIPS64 && !TARGET_BIG_ENDIAN
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply ATI_VGA
@@ -48,6 +56,8 @@ config FULOONG
 
 config LOONGSON3V
 bool
+default y
+depends on MIPS64 && !TARGET_BIG_ENDIAN
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply VIRTIO_PCI
@@ -69,6 +79,8 @@ config MIPS_CPS
 
 config MIPS_BOSTON
 bool
+default y
+depends on MIPS64 && !TARGET_BIG_ENDIAN
 imply PCI_DEVICES
 imply TEST_DEVICES
 select FITLOADER
-- 
2.44.0

[PATCH 08/22] loongarch: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Loongarch.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/loongarch64-softmmu/default.mak | 3 ++-
 hw/loongarch/Kconfig| 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/devices/loongarch64-softmmu/default.mak 
b/configs/devices/loongarch64-softmmu/default.mak
index 0893112b81d..ffe705836fd 100644
--- a/configs/devices/loongarch64-softmmu/default.mak
+++ b/configs/devices/loongarch64-softmmu/default.mak
@@ -3,4 +3,5 @@
 # Uncomment the following lines to disable these optional devices:
 # CONFIG_PCI_DEVICES=n
 
-CONFIG_LOONGARCH_VIRT=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_LOONGARCH_VIRT=n
diff --git a/hw/loongarch/Kconfig b/hw/loongarch/Kconfig
index 5727efed6d8..78640505630 100644
--- a/hw/loongarch/Kconfig
+++ b/hw/loongarch/Kconfig
@@ -1,5 +1,7 @@
 config LOONGARCH_VIRT
 bool
+default y
+depends on LOONGARCH64
 select PCI
 select PCI_EXPRESS_GENERIC_BRIDGE
 imply VIRTIO_VGA
-- 
2.44.0

[PATCH 20/22] sparc: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with SPARC and SPARC64.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/sparc-softmmu/default.mak   | 7 +++
 configs/devices/sparc64-softmmu/default.mak | 7 +++
 hw/sparc/Kconfig| 4 
 hw/sparc64/Kconfig  | 4 
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/configs/devices/sparc-softmmu/default.mak 
b/configs/devices/sparc-softmmu/default.mak
index ee852181151..87668fda5ea 100644
--- a/configs/devices/sparc-softmmu/default.mak
+++ b/configs/devices/sparc-softmmu/default.mak
@@ -5,7 +5,6 @@
 #CONFIG_TCX=n
 #CONFIG_CG3=n
 
-# Boards:
-#
-CONFIG_SUN4M=y
-CONFIG_LEON3=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_SUN4M=n
+# CONFIG_LEON3=n
diff --git a/configs/devices/sparc64-softmmu/default.mak 
b/configs/devices/sparc64-softmmu/default.mak
index e50030a229c..fa82f39a200 100644
--- a/configs/devices/sparc64-softmmu/default.mak
+++ b/configs/devices/sparc64-softmmu/default.mak
@@ -6,7 +6,6 @@
 #CONFIG_SUNHME=n
 #CONFIG_TEST_DEVICES=n
 
-# Boards:
-#
-CONFIG_SUN4U=y
-CONFIG_NIAGARA=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_SUN4U=n
+# CONFIG_NIAGARA=n
diff --git a/hw/sparc/Kconfig b/hw/sparc/Kconfig
index 79d58beb7a6..3cc165dbfb7 100644
--- a/hw/sparc/Kconfig
+++ b/hw/sparc/Kconfig
@@ -1,5 +1,7 @@
 config SUN4M
 bool
+default y
+depends on SPARC && !SPARC64
 imply TCX
 imply CG3
 select CS4231
@@ -18,6 +20,8 @@ config SUN4M
 
 config LEON3
 bool
+default y
+depends on SPARC && !SPARC64
 select GRLIB
 
 config GRLIB
diff --git a/hw/sparc64/Kconfig b/hw/sparc64/Kconfig
index 7e557ad17b0..3b948a22907 100644
--- a/hw/sparc64/Kconfig
+++ b/hw/sparc64/Kconfig
@@ -1,5 +1,7 @@
 config SUN4U
 bool
+default y
+depends on SPARC64
 imply PCI_DEVICES
 imply SUNHME
 imply TEST_DEVICES
@@ -16,6 +18,8 @@ config SUN4U
 
 config NIAGARA
 bool
+default y
+depends on SPARC64
 select EMPTY_SLOT
 select SUN4V_RTC
 select UNIMP
-- 
2.44.0

[PATCH 13/22] nios2: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Nios2.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/nios2-softmmu/default.mak | 7 +++
 hw/nios2/Kconfig  | 9 -
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/configs/devices/nios2-softmmu/default.mak 
b/configs/devices/nios2-softmmu/default.mak
index e130d024e62..50a68d26b0f 100644
--- a/configs/devices/nios2-softmmu/default.mak
+++ b/configs/devices/nios2-softmmu/default.mak
@@ -1,6 +1,5 @@
 # Default configuration for nios2-softmmu
 
-# Boards:
-#
-CONFIG_NIOS2_10M50=y
-CONFIG_NIOS2_GENERIC_NOMMU=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_NIOS2_10M50=n
+# CONFIG_NIOS2_GENERIC_NOMMU=n
diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
index 4748ae27b67..ab7866a5358 100644
--- a/hw/nios2/Kconfig
+++ b/hw/nios2/Kconfig
@@ -1,13 +1,12 @@
 config NIOS2_10M50
 bool
-select NIOS2
+default y
+depends on NIOS2
 select SERIAL
 select ALTERA_TIMER
 select NIOS2_VIC
 
 config NIOS2_GENERIC_NOMMU
 bool
-select NIOS2
-
-config NIOS2
-bool
+default y
+depends on NIOS2
-- 
2.44.0

[PATCH 16/22] riscv: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with RISC-V.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/riscv32-softmmu/default.mak | 13 ++---
 configs/devices/riscv64-softmmu/default.mak | 15 +++
 hw/riscv/Kconfig| 14 ++
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/configs/devices/riscv32-softmmu/default.mak 
b/configs/devices/riscv32-softmmu/default.mak
index 07e4fd26df3..c2cd86ce05f 100644
--- a/configs/devices/riscv32-softmmu/default.mak
+++ b/configs/devices/riscv32-softmmu/default.mak
@@ -4,10 +4,9 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-# Boards:
-#
-CONFIG_SPIKE=y
-CONFIG_SIFIVE_E=y
-CONFIG_SIFIVE_U=y
-CONFIG_RISCV_VIRT=y
-CONFIG_OPENTITAN=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_SPIKE=n
+# CONFIG_SIFIVE_E=n
+# CONFIG_SIFIVE_U=n
+# CONFIG_RISCV_VIRT=n
+# CONFIG_OPENTITAN=n
diff --git a/configs/devices/riscv64-softmmu/default.mak 
b/configs/devices/riscv64-softmmu/default.mak
index 221963d4c5c..39ed3a0061a 100644
--- a/configs/devices/riscv64-softmmu/default.mak
+++ b/configs/devices/riscv64-softmmu/default.mak
@@ -4,11 +4,10 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-# Boards:
-#
-CONFIG_SPIKE=y
-CONFIG_SIFIVE_E=y
-CONFIG_SIFIVE_U=y
-CONFIG_RISCV_VIRT=y
-CONFIG_MICROCHIP_PFSOC=y
-CONFIG_SHAKTI_C=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_SPIKE=n
+# CONFIG_SIFIVE_E=n
+# CONFIG_SIFIVE_U=n
+# CONFIG_RISCV_VIRT=n
+# CONFIG_MICROCHIP_PFSOC=n
+# CONFIG_SHAKTI_C=n
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 5d644eb7b16..b2955a8ae77 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -8,6 +8,8 @@ config IBEX
 
 config MICROCHIP_PFSOC
 bool
+default y
+depends on RISCV64
 select CADENCE_SDHCI
 select MCHP_PFSOC_DMC
 select MCHP_PFSOC_IOSCB
@@ -20,12 +22,16 @@ config MICROCHIP_PFSOC
 
 config OPENTITAN
 bool
+default y
+depends on RISCV32
 select IBEX
 select SIFIVE_PLIC
 select UNIMP
 
 config RISCV_VIRT
 bool
+default y
+depends on RISCV32 || RISCV64
 imply PCI_DEVICES
 imply VIRTIO_VGA
 imply TEST_DEVICES
@@ -50,6 +56,8 @@ config RISCV_VIRT
 
 config SHAKTI_C
 bool
+default y
+depends on RISCV64
 select RISCV_ACLINT
 select SHAKTI_UART
 select SIFIVE_PLIC
@@ -57,6 +65,8 @@ config SHAKTI_C
 
 config SIFIVE_E
 bool
+default y
+depends on RISCV32 || RISCV64
 select RISCV_ACLINT
 select SIFIVE_GPIO
 select SIFIVE_PLIC
@@ -67,6 +77,8 @@ config SIFIVE_E
 
 config SIFIVE_U
 bool
+default y
+depends on RISCV32 || RISCV64
 select CADENCE
 select RISCV_ACLINT
 select SIFIVE_GPIO
@@ -83,6 +95,8 @@ config SIFIVE_U
 
 config SPIKE
 bool
+default y
+depends on RISCV32 || RISCV64
 select RISCV_NUMA
 select HTIF
 select RISCV_ACLINT
-- 
2.44.0

[PATCH 22/22] xtensa: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Xtensa.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/xtensa-softmmu/default.mak | 9 -
 hw/xtensa/Kconfig  | 6 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/configs/devices/xtensa-softmmu/default.mak 
b/configs/devices/xtensa-softmmu/default.mak
index f650cad7609..fbc3079a943 100644
--- a/configs/devices/xtensa-softmmu/default.mak
+++ b/configs/devices/xtensa-softmmu/default.mak
@@ -4,8 +4,7 @@
 #
 #CONFIG_PCI_DEVICES=n
 
-# Boards:
-#
-CONFIG_XTENSA_SIM=y
-CONFIG_XTENSA_VIRT=y
-CONFIG_XTENSA_XTFPGA=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_XTENSA_SIM=n
+# CONFIG_XTENSA_VIRT=n
+# CONFIG_XTENSA_XTFPGA=n
diff --git a/hw/xtensa/Kconfig b/hw/xtensa/Kconfig
index 0740657ea58..443b415c2ba 100644
--- a/hw/xtensa/Kconfig
+++ b/hw/xtensa/Kconfig
@@ -1,14 +1,20 @@
 config XTENSA_SIM
+default y
+depends on XTENSA
 bool
 
 config XTENSA_VIRT
 bool
+default y
+depends on XTENSA
 select XTENSA_SIM
 select PCI_EXPRESS_GENERIC_BRIDGE
 select PCI_DEVICES
 
 config XTENSA_XTFPGA
 bool
+default y
+depends on XTENSA
 select OPENCORES_ETH
 select PFLASH_CFI01
 select SERIAL
-- 
2.44.0

[PATCH 07/22] i386: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with i386.

No changes to generated config-devices.mak files, other than
adding CONFIG_I386 to the x86_64-softmmu target.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/i386-softmmu/default.mak | 11 +--
 hw/i386/Kconfig  | 10 +-
 target/i386/Kconfig  |  1 +
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/configs/devices/i386-softmmu/default.mak 
b/configs/devices/i386-softmmu/default.mak
index 598c6646dfc..448e3e3b1ba 100644
--- a/configs/devices/i386-softmmu/default.mak
+++ b/configs/devices/i386-softmmu/default.mak
@@ -24,9 +24,8 @@
 #CONFIG_VTD=n
 #CONFIG_SGX=n
 
-# Boards:
-#
-CONFIG_ISAPC=y
-CONFIG_I440FX=y
-CONFIG_Q35=y
-CONFIG_MICROVM=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_ISAPC=n
+# CONFIG_I440FX=n
+# CONFIG_Q35=n
+# CONFIG_MICROVM=n
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index a6ee052f9a1..4362164962c 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -66,6 +66,8 @@ config PC_ACPI
 
 config I440FX
 bool
+default y
+depends on I386
 imply E1000_PCI
 imply VMPORT
 imply VMMOUSE
@@ -81,6 +83,8 @@ config I440FX
 
 config ISAPC
 bool
+default y
+depends on I386
 imply VGA_ISA
 select ISA_BUS
 select PC
@@ -91,6 +95,8 @@ config ISAPC
 
 config Q35
 bool
+default y
+depends on I386
 imply VTD
 imply AMD_IOMMU
 imply E1000E_PCI_EXPRESS
@@ -108,6 +114,8 @@ config Q35
 
 config MICROVM
 bool
+default y
+depends on I386
 select SERIAL_ISA # for serial_hds_isa_init()
 select ISA_BUS
 select APIC
@@ -142,4 +150,4 @@ config VMMOUSE
 config XEN_EMU
 bool
 default y
-depends on KVM && (I386 || X86_64)
+depends on KVM && I386
diff --git a/target/i386/Kconfig b/target/i386/Kconfig
index ce6968906ee..3e62fdc7064 100644
--- a/target/i386/Kconfig
+++ b/target/i386/Kconfig
@@ -3,3 +3,4 @@ config I386
 
 config X86_64
 bool
+select I386
-- 
2.44.0

[PATCH 15/22] ppc: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with PowerPC/POWER.

No changes to generated config-devices.mak files, other than
adding CONFIG_PPC to the ppc64-softmmu target.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/ppc-softmmu/default.mak   | 26 ---
 configs/devices/ppc64-softmmu/default.mak |  8 +++
 hw/ppc/Kconfig| 26 +++
 target/ppc/Kconfig|  1 +
 4 files changed, 44 insertions(+), 17 deletions(-)

diff --git a/configs/devices/ppc-softmmu/default.mak 
b/configs/devices/ppc-softmmu/default.mak
index 3061b26749a..460d15e676b 100644
--- a/configs/devices/ppc-softmmu/default.mak
+++ b/configs/devices/ppc-softmmu/default.mak
@@ -4,22 +4,24 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-# For embedded PPCs:
-CONFIG_E500PLAT=y
-CONFIG_MPC8544DS=y
-CONFIG_PPC405=y
-CONFIG_PPC440=y
-CONFIG_VIRTEX=y
+# Boards are selected by default, uncomment to keep out of the build.
+
+# Embedded PPCs:
+# CONFIG_E500PLAT=n
+# CONFIG_MPC8544DS=n
+# CONFIG_PPC405=n
+# CONFIG_PPC440=n
+# CONFIG_VIRTEX=n
 
 # For Sam460ex
-CONFIG_SAM460EX=y
+# CONFIG_SAM460EX=n
 
 # For Macs
-CONFIG_MAC_OLDWORLD=y
-CONFIG_MAC_NEWWORLD=y
+# CONFIG_MAC_OLDWORLD=n
+# CONFIG_MAC_NEWWORLD=n
 
-CONFIG_AMIGAONE=y
-CONFIG_PEGASOS2=y
+# CONFIG_AMIGAONE=n
+# CONFIG_PEGASOS2=n
 
 # For PReP
-CONFIG_PREP=y
+# CONFIG_PREP=n
diff --git a/configs/devices/ppc64-softmmu/default.mak 
b/configs/devices/ppc64-softmmu/default.mak
index b90e5bf4558..e8ad2603133 100644
--- a/configs/devices/ppc64-softmmu/default.mak
+++ b/configs/devices/ppc64-softmmu/default.mak
@@ -3,8 +3,6 @@
 # Include all 32-bit boards
 include ../ppc-softmmu/default.mak
 
-# For PowerNV
-CONFIG_POWERNV=y
-
-# For pSeries
-CONFIG_PSERIES=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_POWERNV=n
+# CONFIG_PSERIES=n
diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
index 37ccf9cdcaf..78f83e78ce5 100644
--- a/hw/ppc/Kconfig
+++ b/hw/ppc/Kconfig
@@ -1,5 +1,7 @@
 config PSERIES
 bool
+default y
+depends on PPC64
 imply USB_OHCI_PCI
 imply PCI_DEVICES
 imply TEST_DEVICES
@@ -23,6 +25,8 @@ config SPAPR_RNG
 
 config POWERNV
 bool
+default y
+depends on PPC64
 imply PCI_DEVICES
 imply TEST_DEVICES
 select ISA_IPMI_BT
@@ -38,6 +42,8 @@ config POWERNV
 
 config PPC405
 bool
+default y
+depends on PPC
 select M48T59
 select PFLASH_CFI02
 select PPC4XX
@@ -45,6 +51,8 @@ config PPC405
 
 config PPC440
 bool
+default y
+depends on PPC
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply E1000_PCI
@@ -62,6 +70,8 @@ config PPC4XX
 
 config SAM460EX
 bool
+default y
+depends on PPC
 select PFLASH_CFI01
 select IDE_SII3112
 select M41T80
@@ -75,6 +85,8 @@ config SAM460EX
 
 config AMIGAONE
 bool
+default y
+depends on PPC
 imply ATI_VGA
 select ARTICIA
 select VT82C686
@@ -82,6 +94,8 @@ config AMIGAONE
 
 config PEGASOS2
 bool
+default y
+depends on PPC
 imply ATI_VGA
 select MV64361
 select VT82C686
@@ -90,6 +104,8 @@ config PEGASOS2
 
 config PREP
 bool
+default y
+depends on PPC
 imply PCI_DEVICES
 imply TEST_DEVICES
 select CS4231A
@@ -106,6 +122,8 @@ config RS6000_MC
 
 config MAC_OLDWORLD
 bool
+default y
+depends on PPC
 imply PCI_DEVICES
 imply SUNGEM
 imply TEST_DEVICES
@@ -117,6 +135,8 @@ config MAC_OLDWORLD
 
 config MAC_NEWWORLD
 bool
+default y
+depends on PPC
 imply PCI_DEVICES
 imply SUNGEM
 imply TEST_DEVICES
@@ -147,14 +167,20 @@ config E500
 
 config E500PLAT
 bool
+default y
+depends on PPC
 select E500
 
 config MPC8544DS
 bool
+default y
+depends on PPC
 select E500
 
 config VIRTEX
 bool
+default y
+depends on PPC
 select PPC4XX
 select PFLASH_CFI01
 select SERIAL
diff --git a/target/ppc/Kconfig b/target/ppc/Kconfig
index 3ff152051a3..0283711673e 100644
--- a/target/ppc/Kconfig
+++ b/target/ppc/Kconfig
@@ -3,3 +3,4 @@ config PPC
 
 config PPC64
 bool
+select PPC
-- 
2.44.0

[PATCH 21/22] tricore: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with TriCore.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/tricore-softmmu/default.mak | 7 +--
 hw/tricore/Kconfig  | 4 
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/configs/devices/tricore-softmmu/default.mak 
b/configs/devices/tricore-softmmu/default.mak
index cb8fc286eb2..c7ab542244b 100644
--- a/configs/devices/tricore-softmmu/default.mak
+++ b/configs/devices/tricore-softmmu/default.mak
@@ -1,2 +1,5 @@
-CONFIG_TRICORE_TESTBOARD=y
-CONFIG_TRIBOARD=y
+# Default configuration for tricore-softmmu
+
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_TRICORE_TESTBOARD=n
+# CONFIG_TRIBOARD=n
diff --git a/hw/tricore/Kconfig b/hw/tricore/Kconfig
index 33c1e852c33..6c04f64949d 100644
--- a/hw/tricore/Kconfig
+++ b/hw/tricore/Kconfig
@@ -1,8 +1,12 @@
 config TRICORE_TESTBOARD
+default y
+depends on TRICORE
 bool
 
 config TRIBOARD
 bool
+default y
+depends on TRICORE
 select TC27X_SOC
 
 config TC27X_SOC
-- 
2.44.0

[PATCH 18/22] s390x: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with s390.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/s390x-softmmu/default.mak | 5 ++---
 hw/s390x/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/devices/s390x-softmmu/default.mak 
b/configs/devices/s390x-softmmu/default.mak
index 6d87bc8b4b0..340c1092922 100644
--- a/configs/devices/s390x-softmmu/default.mak
+++ b/configs/devices/s390x-softmmu/default.mak
@@ -9,6 +9,5 @@
 #CONFIG_WDT_DIAG288=n
 #CONFIG_PCIE_DEVICES=n
 
-# Boards:
-#
-CONFIG_S390_CCW_VIRTIO=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_S390_CCW_VIRTIO=n
diff --git a/hw/s390x/Kconfig b/hw/s390x/Kconfig
index 26ad1044858..3bbf4ae56e4 100644
--- a/hw/s390x/Kconfig
+++ b/hw/s390x/Kconfig
@@ -1,5 +1,7 @@
 config S390_CCW_VIRTIO
 bool
+default y
+depends on S390X
 imply VIRTIO_PCI
 imply TERMINAL3270
 imply VFIO_AP
-- 
2.44.0

[PATCH 09/22] m68k: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with m68k.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/m68k-softmmu/default.mak | 13 ++---
 hw/m68k/Kconfig  | 10 ++
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/configs/devices/m68k-softmmu/default.mak 
b/configs/devices/m68k-softmmu/default.mak
index 8dcaa28ed38..3ceda6b041b 100644
--- a/configs/devices/m68k-softmmu/default.mak
+++ b/configs/devices/m68k-softmmu/default.mak
@@ -1,9 +1,8 @@
 # Default configuration for m68k-softmmu
 
-# Boards:
-#
-CONFIG_AN5206=y
-CONFIG_MCF5208=y
-CONFIG_NEXTCUBE=y
-CONFIG_Q800=y
-CONFIG_M68K_VIRT=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_AN5206=n
+# CONFIG_MCF5208=n
+# CONFIG_NEXTCUBE=n
+# CONFIG_Q800=n
+# CONFIG_M68K_VIRT=n
diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
index d88741ec9d1..0092cda4e9c 100644
--- a/hw/m68k/Kconfig
+++ b/hw/m68k/Kconfig
@@ -1,20 +1,28 @@
 config AN5206
 bool
+default y
+depends on M68K
 select COLDFIRE
 select PTIMER
 
 config MCF5208
 bool
+default y
+depends on M68K
 select COLDFIRE
 select PTIMER
 
 config NEXTCUBE
 bool
+default y
+depends on M68K
 select FRAMEBUFFER
 select ESCC
 
 config Q800
 bool
+default y
+depends on M68K
 select MAC_VIA
 select NUBUS
 select MACFB
@@ -29,6 +37,8 @@ config Q800
 
 config M68K_VIRT
 bool
+default y
+depends on M68K
 select M68K_IRQC
 select VIRT_CTRL
 select GOLDFISH_PIC
-- 
2.44.0

[PATCH 10/22] microblaze: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Microblaze.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/microblaze-softmmu/default.mak | 9 -
 hw/microblaze/Kconfig  | 6 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/configs/devices/microblaze-softmmu/default.mak 
b/configs/devices/microblaze-softmmu/default.mak
index db8c6e4bba3..583e3959bb7 100644
--- a/configs/devices/microblaze-softmmu/default.mak
+++ b/configs/devices/microblaze-softmmu/default.mak
@@ -1,7 +1,6 @@
 # Default configuration for microblaze-softmmu
 
-# Boards:
-#
-CONFIG_PETALOGIX_S3ADSP1800=y
-CONFIG_PETALOGIX_ML605=y
-CONFIG_XLNX_ZYNQMP_PMU=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_PETALOGIX_S3ADSP1800=n
+# CONFIG_PETALOGIX_ML605=n
+# CONFIG_XLNX_ZYNQMP_PMU=n
diff --git a/hw/microblaze/Kconfig b/hw/microblaze/Kconfig
index e2697ced9cc..d78ba843fac 100644
--- a/hw/microblaze/Kconfig
+++ b/hw/microblaze/Kconfig
@@ -1,5 +1,7 @@
 config PETALOGIX_S3ADSP1800
 bool
+default y
+depends on MICROBLAZE
 select PFLASH_CFI01
 select XILINX
 select XILINX_AXI
@@ -8,6 +10,8 @@ config PETALOGIX_S3ADSP1800
 
 config PETALOGIX_ML605
 bool
+default y
+depends on MICROBLAZE
 select PFLASH_CFI01
 select SERIAL
 select SSI_M25P80
@@ -18,4 +22,6 @@ config PETALOGIX_ML605
 
 config XLNX_ZYNQMP_PMU
 bool
+default y
+depends on MICROBLAZE
 select XLNX_ZYNQMP
-- 
2.44.0

[PATCH 04/22] avr: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with AVR.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/avr-softmmu/default.mak | 5 ++---
 hw/avr/Kconfig  | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/configs/devices/avr-softmmu/default.mak 
b/configs/devices/avr-softmmu/default.mak
index 80218add98c..4207e7b3ce2 100644
--- a/configs/devices/avr-softmmu/default.mak
+++ b/configs/devices/avr-softmmu/default.mak
@@ -1,5 +1,4 @@
 # Default configuration for avr-softmmu
 
-# Boards:
-#
-CONFIG_ARDUINO=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_ARDUINO=n
diff --git a/hw/avr/Kconfig b/hw/avr/Kconfig
index d31298c3cce..b29937be414 100644
--- a/hw/avr/Kconfig
+++ b/hw/avr/Kconfig
@@ -5,5 +5,8 @@ config AVR_ATMEGA_MCU
 select AVR_POWER
 
 config ARDUINO
+bool
+default y
+depends on AVR
 select AVR_ATMEGA_MCU
 select UNIMP
-- 
2.44.0

[PATCH 11/22] meson: make target endianneess available to Kconfig

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
MIPS boards may only be available for big-endian or only for
little-endian emulators, add a symbol so that this can be described
with a "depends on" clause.

Signed-off-by: Paolo Bonzini 
---
 meson.build| 12 +++-
 target/Kconfig |  3 +++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index 9af60550753..9c4fb027853 100644
--- a/meson.build
+++ b/meson.build
@@ -3037,7 +3037,7 @@ foreach target : target_dirs
 }
   endif
 
-  accel_kconfig = []
+  target_kconfig = []
   foreach sym: accelerators
 if sym == 'CONFIG_TCG' or target in accelerator_targets.get(sym, [])
   config_target += { sym: 'y' }
@@ -3047,10 +3047,10 @@ foreach target : target_dirs
   else
 config_target += { 'CONFIG_TCG_BUILTIN': 'y' }
   endif
-  accel_kconfig += [ sym + '=y' ]
+  target_kconfig += [ sym + '=y' ]
 endif
   endforeach
-  if accel_kconfig.length() == 0
+  if target_kconfig.length() == 0
 if default_targets
   continue
 endif
@@ -3110,6 +3110,9 @@ foreach target : target_dirs
configuration: 
config_target_data)}
 
   if target.endswith('-softmmu')
+target_kconfig += 'CONFIG_' + config_target['TARGET_ARCH'].to_upper() + 
'=y'
+target_kconfig += 'CONFIG_TARGET_BIG_ENDIAN=' + 
config_target['TARGET_BIG_ENDIAN']
+
 config_input = meson.get_external_property(target, 'default')
 config_devices_mak = target + '-config-devices.mak'
 config_devices_mak = configure_file(
@@ -3120,8 +3123,7 @@ foreach target : target_dirs
   command: [minikconf,
 get_option('default_devices') ? '--defconfig' : 
'--allnoconfig',
 config_devices_mak, '@DEPFILE@', '@INPUT@',
-host_kconfig, accel_kconfig,
-'CONFIG_' + config_target['TARGET_ARCH'].to_upper() + '=y'])
+host_kconfig, target_kconfig])
 
 config_devices_data = configuration_data()
 config_devices = keyval.load(config_devices_mak)
diff --git a/target/Kconfig b/target/Kconfig
index 83da0bd2938..afc00dea30c 100644
--- a/target/Kconfig
+++ b/target/Kconfig
@@ -18,3 +18,6 @@ source sh4/Kconfig
 source sparc/Kconfig
 source tricore/Kconfig
 source xtensa/Kconfig
+
+config TARGET_BIG_ENDIAN
+bool
-- 
2.44.0

[PATCH 05/22] cris: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with CRIS.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/cris-softmmu/default.mak | 5 ++---
 hw/cris/Kconfig  | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/devices/cris-softmmu/default.mak 
b/configs/devices/cris-softmmu/default.mak
index 5932cf4d06f..ff73cd40847 100644
--- a/configs/devices/cris-softmmu/default.mak
+++ b/configs/devices/cris-softmmu/default.mak
@@ -1,5 +1,4 @@
 # Default configuration for cris-softmmu
 
-# Boards:
-#
-CONFIG_AXIS=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_AXIS=n
diff --git a/hw/cris/Kconfig b/hw/cris/Kconfig
index 884ad2cbc0d..26c7eef7437 100644
--- a/hw/cris/Kconfig
+++ b/hw/cris/Kconfig
@@ -1,5 +1,7 @@
 config AXIS
 bool
+default y
+depends on CRIS
 select ETRAXFS
 select PFLASH_CFI02
 select NAND
-- 
2.44.0

[PATCH 19/22] sh4: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with SH.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/sh4-softmmu/default.mak | 7 +++
 hw/sh4/Kconfig  | 4 
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/configs/devices/sh4-softmmu/default.mak 
b/configs/devices/sh4-softmmu/default.mak
index 565e8b0b5df..c06a427053a 100644
--- a/configs/devices/sh4-softmmu/default.mak
+++ b/configs/devices/sh4-softmmu/default.mak
@@ -5,7 +5,6 @@
 #CONFIG_PCI_DEVICES=n
 #CONFIG_TEST_DEVICES=n
 
-# Boards:
-#
-CONFIG_R2D=y
-CONFIG_SHIX=y
+# Boards are selected by default, uncomment to keep out of the build.
+# CONFIG_R2D=n
+# CONFIG_SHIX=n
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index e0c4ecd1a53..99a76a94c3f 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -1,5 +1,7 @@
 config R2D
 bool
+default y
+depends on SH4
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply RTL8139_PCI
@@ -13,6 +15,8 @@ config R2D
 
 config SHIX
 bool
+default y
+depends on SH4
 select SH7750
 select TC58128
 
-- 
2.44.0

[PATCH 14/22] openrisc: switch boards to "default y"

[Paolo Bonzini]

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with OpenRISC.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
 configs/devices/or1k-softmmu/default.mak | 5 ++---
 hw/openrisc/Kconfig  | 4 
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/configs/devices/or1k-softmmu/default.mak 
b/configs/devices/or1k-softmmu/default.mak
index 3aecdf9d738..efe3bc278bc 100644
--- a/configs/devices/or1k-softmmu/default.mak
+++ b/configs/devices/or1k-softmmu/default.mak
@@ -5,6 +5,5 @@
 # CONFIG_TEST_DEVICES=n
 
 # Boards:
-#
-CONFIG_OR1K_SIM=y
-CONFIG_OR1K_VIRT=y
+# CONFIG_OR1K_SIM=n
+# CONFIG_OR1K_VIRT=n
diff --git a/hw/openrisc/Kconfig b/hw/openrisc/Kconfig
index 97af258b556..9c9015e0a5d 100644
--- a/hw/openrisc/Kconfig
+++ b/hw/openrisc/Kconfig
@@ -1,5 +1,7 @@
 config OR1K_SIM
 bool
+default y
+depends on OPENRISC
 select SERIAL
 select OPENCORES_ETH
 select OMPIC
@@ -7,6 +9,8 @@ config OR1K_SIM
 
 config OR1K_VIRT
 bool
+default y
+depends on OPENRISC
 imply PCI_DEVICES
 imply VIRTIO_VGA
 imply TEST_DEVICES
-- 
2.44.0

Re: [PATCH 04/22] avr: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with AVR.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/avr-softmmu/default.mak | 5 ++---
  hw/avr/Kconfig  | 3 +++
  2 files changed, 5 insertions(+), 3 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 17/22] rx: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with RX.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/rx-softmmu/default.mak | 3 ++-
  hw/rx/Kconfig  | 2 ++
  2 files changed, 4 insertions(+), 1 deletion(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 19/22] sh4: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with SH.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/sh4-softmmu/default.mak | 7 +++
  hw/sh4/Kconfig  | 4 
  2 files changed, 7 insertions(+), 4 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 21/22] tricore: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with TriCore.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/tricore-softmmu/default.mak | 7 +--
  hw/tricore/Kconfig  | 4 
  2 files changed, 9 insertions(+), 2 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v2 1/1] migration/dirtyrate: Fix segmentation fault

[Peter Xu]

On Tue, Apr 23, 2024 at 09:13:08AM +, Masato Imai wrote:
> When the KVM acceleration parameter is not set, executing calc_dirty_rate
> with the -r or -b option results in a segmentation fault due to accessing
> a null kvm_state pointer in the kvm_dirty_ring_enabled function.
> This commit adds a check for kvm_enabled to prevent segmentation faults.
> 
> Signed-off-by: Masato Imai 
> ---
>  migration/dirtyrate.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 1d2e85746f..2a7df52519 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -799,6 +799,13 @@ void qmp_calc_dirty_rate(int64_t calc_time,
>   * dirty ring mode only works when kvm dirty ring is enabled.
>   * on the contrary, dirty bitmap mode is not.
>   */
> +if (!kvm_enabled() &&
> +(mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING ||
> + mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP)) {
> +error_setg(errp, "mode %s requires kvm to be enabled.",
> + DirtyRateMeasureMode_str(mode));
> +return;
> +}

Logically dirty bitmap should work with tcg.  So the other option is to let
kvm_dirty_ring_enabled() check kvm_state too and return false if
kvm_state==NULL?

>  if (((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) &&
>  !kvm_dirty_ring_enabled()) ||
>  ((mode == DIRTY_RATE_MEASURE_MODE_DIRTY_BITMAP) &&
> -- 
> 2.34.1
> 

-- 
Peter Xu

Re: [PATCH 22/22] xtensa: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Xtensa.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/xtensa-softmmu/default.mak | 9 -
  hw/xtensa/Kconfig  | 6 ++
  2 files changed, 10 insertions(+), 5 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 10/22] microblaze: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Microblaze.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/microblaze-softmmu/default.mak | 9 -
  hw/microblaze/Kconfig  | 6 ++
  2 files changed, 10 insertions(+), 5 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 09/22] m68k: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with m68k.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/m68k-softmmu/default.mak | 13 ++---
  hw/m68k/Kconfig  | 10 ++
  2 files changed, 16 insertions(+), 7 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 06/22] hppa: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with PARISC.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/hppa-softmmu/default.mak | 5 ++---
  hw/hppa/Kconfig  | 2 ++
  2 files changed, 4 insertions(+), 3 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 05/22] cris: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with CRIS.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/cris-softmmu/default.mak | 5 ++---
  hw/cris/Kconfig  | 2 ++
  2 files changed, 4 insertions(+), 3 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 02/22] alpha: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Start with Alpha.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/alpha-softmmu/default.mak | 5 ++---
  hw/alpha/Kconfig  | 2 ++
  2 files changed, 4 insertions(+), 3 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 08/22] loongarch: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:15, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Loongarch.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/loongarch64-softmmu/default.mak | 3 ++-
  hw/loongarch/Kconfig| 2 ++
  2 files changed, 4 insertions(+), 1 deletion(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 14/22] openrisc: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with OpenRISC.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/or1k-softmmu/default.mak | 5 ++---
  hw/openrisc/Kconfig  | 4 
  2 files changed, 6 insertions(+), 3 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 13/22] nios2: switch boards to "default y"

[Philippe Mathieu-Daudé]

On 23/4/24 15:16, Paolo Bonzini wrote:

Some targets use "default y" for boards to filter out those that require
TCG.  For consistency we are switching all other targets to do the same.
Continue with Nios2.

No changes to generated config-devices.mak file.

Signed-off-by: Paolo Bonzini 
---
  configs/devices/nios2-softmmu/default.mak | 7 +++
  hw/nios2/Kconfig  | 9 -
  2 files changed, 7 insertions(+), 9 deletions(-)


Hopefully this gone will be gone before you get a chance
to merge this commit =)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v10 1/6] ui/gtk: Check if fence_fd is equal to or greater than 0

[Daniel P . Berrangé]

On Mon, Apr 22, 2024 at 07:22:48PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim 
> 
> 'fence_fd' needs to be validated always before being referenced
> And the passing condition should include '== 0' as 0 is a valid
> value for the file descriptor.
> 
> Suggested-by: Marc-André Lureau 
> Cc: Philippe Mathieu-Daudé 
> Cc: Daniel P. Berrangé 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---
>  ui/gtk-egl.c |  2 +-
>  ui/gtk-gl-area.c |  2 +-
>  ui/gtk.c | 10 ++
>  3 files changed, 8 insertions(+), 6 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH-for-9.0? 01/21] host/atomic128: Include missing 'qemu/atomic.h' header

[Philippe Mathieu-Daudé]

On 21/3/24 18:05, Richard Henderson wrote:

On 3/21/24 05:48, Philippe Mathieu-Daudé wrote:

qatomic_cmpxchg__nocheck(), qatomic_read__nocheck(),
qatomic_set__nocheck() are defined in "qemu/atomic.h".
Include it in order to avoid:

   In file included from include/exec/helper-proto.h:10:
   In file included from include/exec/helper-proto-common.h:10:
   In file included from include/qemu/atomic128.h:61:
   In file included from host/include/aarch64/host/atomic128-cas.h:16:
   host/include/generic/host/atomic128-cas.h:23:11: error: call to 
undeclared function 'qatomic_cmpxchg__nocheck'; ISO C99 and later do 
not support implicit function declarations 
[-Wimplicit-function-declaration]

 r.i = qatomic_cmpxchg__nocheck(ptr_align, c.i, n.i);



Nak.  We can rename these host/include/*/host/*atomic* as .h.inc if you 
need, but the top-level header is include/qemu/atomic128.h.


Patch available here:
https://lore.kernel.org/qemu-devel/20240418160943.95047-3-phi...@linaro.org/

Re: [PATCH v10 2/6] ui/console: new dmabuf.h and dmabuf.c for QemuDmaBuf struct and helpers

[Daniel P . Berrangé]

On Mon, Apr 22, 2024 at 07:22:49PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim 
> 
> New header and source files are added for containing QemuDmaBuf struct
> definition and newly introduced helpers for creating/freeing the struct
> and accessing its data.
> 
> v10: Change the license type for both dmabuf.h and dmabuf.c from MIT to
>  GPL to be in line with QEMU's default license
>  (Daniel P. Berrangé )

FYI, in future, notes about changes made in each version would
best go after the '---', since they're not something we need to
record in the commit message once merged. Don't re-send the series
now just for that reason though - whomever merges can trim this.

> 
> Suggested-by: Marc-André Lureau 
> Cc: Philippe Mathieu-Daudé 
> Cc: Daniel P. Berrangé 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---
>  include/ui/console.h |  20 +
>  include/ui/dmabuf.h  |  64 +++
>  ui/dmabuf.c  | 189 +++
>  ui/meson.build   |   1 +
>  4 files changed, 255 insertions(+), 19 deletions(-)
>  create mode 100644 include/ui/dmabuf.h
>  create mode 100644 ui/dmabuf.c

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH v10 2/6] ui/console: new dmabuf.h and dmabuf.c for QemuDmaBuf struct and helpers

[Daniel P . Berrangé]

On Mon, Apr 22, 2024 at 07:22:49PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim 
> 
> New header and source files are added for containing QemuDmaBuf struct
> definition and newly introduced helpers for creating/freeing the struct
> and accessing its data.
> 
> v10: Change the license type for both dmabuf.h and dmabuf.c from MIT to
>  GPL to be in line with QEMU's default license
>  (Daniel P. Berrangé )
> 
> Suggested-by: Marc-André Lureau 
> Cc: Philippe Mathieu-Daudé 
> Cc: Daniel P. Berrangé 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---
>  include/ui/console.h |  20 +
>  include/ui/dmabuf.h  |  64 +++
>  ui/dmabuf.c  | 189 +++
>  ui/meson.build   |   1 +
>  4 files changed, 255 insertions(+), 19 deletions(-)
>  create mode 100644 include/ui/dmabuf.h
>  create mode 100644 ui/dmabuf.c
> 
> diff --git a/include/ui/console.h b/include/ui/console.h
> index 0bc7a00ac0..a208a68b88 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -7,6 +7,7 @@
>  #include "qapi/qapi-types-ui.h"
>  #include "ui/input.h"
>  #include "ui/surface.h"
> +#include "ui/dmabuf.h"
>  
>  #define TYPE_QEMU_CONSOLE "qemu-console"
>  OBJECT_DECLARE_TYPE(QemuConsole, QemuConsoleClass, QEMU_CONSOLE)
> @@ -185,25 +186,6 @@ struct QEMUGLParams {
>  int minor_ver;
>  };
>  
> -typedef struct QemuDmaBuf {
> -int   fd;
> -uint32_t  width;
> -uint32_t  height;
> -uint32_t  stride;
> -uint32_t  fourcc;
> -uint64_t  modifier;
> -uint32_t  texture;
> -uint32_t  x;
> -uint32_t  y;
> -uint32_t  backing_width;
> -uint32_t  backing_height;
> -bool  y0_top;
> -void  *sync;
> -int   fence_fd;
> -bool  allow_fences;
> -bool  draw_submitted;
> -} QemuDmaBuf;
> -
>  enum display_scanout {
>  SCANOUT_NONE,
>  SCANOUT_SURFACE,
> diff --git a/include/ui/dmabuf.h b/include/ui/dmabuf.h
> new file mode 100644
> index 00..7a60116ee6
> --- /dev/null
> +++ b/include/ui/dmabuf.h
> @@ -0,0 +1,64 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * QemuDmaBuf struct and helpers used for accessing its data
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#ifndef DMABUF_H
> +#define DMABUF_H
> +
> +typedef struct QemuDmaBuf {
> +int   fd;
> +uint32_t  width;
> +uint32_t  height;
> +uint32_t  stride;
> +uint32_t  fourcc;
> +uint64_t  modifier;
> +uint32_t  texture;
> +uint32_t  x;
> +uint32_t  y;
> +uint32_t  backing_width;
> +uint32_t  backing_height;
> +bool  y0_top;
> +void  *sync;
> +int   fence_fd;
> +bool  allow_fences;
> +bool  draw_submitted;
> +} QemuDmaBuf;
> +
> +QemuDmaBuf *qemu_dmabuf_new(uint32_t width, uint32_t height,
> +   uint32_t stride, uint32_t x,
> +   uint32_t y, uint32_t backing_width,
> +   uint32_t backing_height, uint32_t fourcc,
> +   uint64_t modifier, int32_t dmabuf_fd,

Should be 'int' not 'int32_t' for FDs.

> +   bool allow_fences, bool y0_top);
> +void qemu_dmabuf_free(QemuDmaBuf *dmabuf);
> +
> +G_DEFINE_AUTOPTR_CLEANUP_FUNC(QemuDmaBuf, qemu_dmabuf_free);
> +
> +int32_t qemu_dmabuf_get_fd(QemuDmaBuf *dmabuf);

Again should be 'int' not 'int42_t'

I think there ought to also be a

  int qemu_dmabuf_dup_fd(QemuDmaBuf *dmabuf);

to do the dup() call in one go too

> diff --git a/ui/dmabuf.c b/ui/dmabuf.c
> new file mode 100644
> index 00..f447cce4fe
> --- /dev/null
> +++ b/ui/dmabuf.c

> +
> +void qemu_dmabuf_free(QemuDmaBuf *dmabuf)
> +{
> +if (dmabuf == NULL) {
> +return;
> +}
> +

I think this method should be made to call

  qemu_dmabuf_close()

to release the FD, if not already released, otherwise
this method could be a resource leak.

> +g_free(dmabuf);
> +}
> +

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

hppa-firmware.img missing build-id

[Cole Robinson]

Hi,

hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
build-id annotations. rpm builds on Fedora will error if an ELF binary
doesn't have build-id:

RPM build errors:
Missing build-id in
/tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware.img
Missing build-id in
/tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware64.img
Generating build-id links failed

I didn't hit this with qemu 8.2.* builds FWIW

Thoughts?

Thanks,
Cole

Re: [PATCH v10 3/6] ui/console: Use qemu_dmabuf_get_..() helpers instead

[Daniel P . Berrangé]

On Mon, Apr 22, 2024 at 07:22:50PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim 
> 
> This commit updates all instances where fields within the QemuDmaBuf
> struct are directly accessed, replacing them with calls to these new
> helper functions.
> 
> v6: fix typos in helper names in ui/spice-display.c
> 
> v7: removed prefix, "dpy_gl_" from all helpers
> 
> v8: Introduction of helpers was removed as those were already added
> by the previous commit
> 
> Suggested-by: Marc-André Lureau 
> Reviewed-by: Marc-André Lureau 
> Cc: Philippe Mathieu-Daudé 
> Cc: Daniel P. Berrangé 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---
>  hw/display/vhost-user-gpu.c |  6 ++--
>  hw/display/virtio-gpu-udmabuf.c |  7 +++--
>  hw/vfio/display.c   | 15 +++---
>  ui/console.c|  4 +--
>  ui/dbus-console.c   |  9 --
>  ui/dbus-listener.c  | 43 +---
>  ui/egl-headless.c   | 23 ++-
>  ui/egl-helpers.c| 47 ++-
>  ui/gtk-egl.c| 48 ---
>  ui/gtk-gl-area.c| 37 
>  ui/gtk.c|  6 ++--
>  ui/spice-display.c  | 50 +++--
>  12 files changed, 187 insertions(+), 108 deletions(-)
> 
> diff --git a/hw/display/vhost-user-gpu.c b/hw/display/vhost-user-gpu.c
> index 709c8a02a1..ea9a6c5d10 100644
> --- a/hw/display/vhost-user-gpu.c
> +++ b/hw/display/vhost-user-gpu.c
> @@ -249,6 +249,7 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
> VhostUserGpuMsg *msg)
>  case VHOST_USER_GPU_DMABUF_SCANOUT: {
>  VhostUserGpuDMABUFScanout *m = &msg->payload.dmabuf_scanout;
>  int fd = qemu_chr_fe_get_msgfd(&g->vhost_chr);
> +int old_fd;
>  QemuDmaBuf *dmabuf;
>  
>  if (m->scanout_id >= g->parent_obj.conf.max_outputs) {
> @@ -262,8 +263,9 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
> VhostUserGpuMsg *msg)
>  g->parent_obj.enable = 1;
>  con = g->parent_obj.scanout[m->scanout_id].con;
>  dmabuf = &g->dmabuf[m->scanout_id];
> -if (dmabuf->fd >= 0) {
> -close(dmabuf->fd);
> +old_fd = qemu_dmabuf_get_fd(dmabuf);
> +if (old_fd >= 0) {
> +close(old_fd);
>  dmabuf->fd = -1;

I think we shoul hdave a qemu_dmabuf_close() method for this logic


> diff --git a/hw/vfio/display.c b/hw/vfio/display.c
> index 1aa440c663..4861c8161d 100644
> --- a/hw/vfio/display.c
> +++ b/hw/vfio/display.c
> @@ -259,9 +259,13 @@ static VFIODMABuf *vfio_display_get_dmabuf(VFIOPCIDevice 
> *vdev,
>  
>  static void vfio_display_free_one_dmabuf(VFIODisplay *dpy, VFIODMABuf 
> *dmabuf)
>  {
> +int fd;
> +
>  QTAILQ_REMOVE(&dpy->dmabuf.bufs, dmabuf, next);
> +
> +fd = qemu_dmabuf_get_fd(&dmabuf->buf);
>  dpy_gl_release_dmabuf(dpy->con, &dmabuf->buf);
> -close(dmabuf->buf.fd);
> +close(fd);

Again, we should have a qemu_dmabuf_close() method

>  g_free(dmabuf);
>  }
>  


>  } else {
> -trace_qemu_spice_gl_forward_dmabuf(ssd->qxl.id,
> -   dmabuf->width, 
> dmabuf->height);
> +stride = qemu_dmabuf_get_stride(dmabuf);
> +fourcc = qemu_dmabuf_get_fourcc(dmabuf);
> +y_0_top = qemu_dmabuf_get_y0_top(dmabuf);
> +fd = qemu_dmabuf_get_fd(dmabuf);

This is where it would use a qemu_dmabuf_dup_fd(), avoiding
the subsequent dup() in the method call

> +
> +trace_qemu_spice_gl_forward_dmabuf(ssd->qxl.id, width, height);
>  /* note: spice server will close the fd, so hand over a dup */
> -spice_qxl_gl_scanout(&ssd->qxl, dup(dmabuf->fd),
> - dmabuf->width, dmabuf->height,
> - dmabuf->stride, dmabuf->fourcc,
> - dmabuf->y0_top);
> +spice_qxl_gl_scanout(&ssd->qxl, dup(fd), width, height,
> + stride, fourcc, y_0_top);
>  }
> -qemu_spice_gl_monitor_config(ssd, 0, 0, dmabuf->width, 
> dmabuf->height);
> +qemu_spice_gl_monitor_config(ssd, 0, 0, width, height);
>  ssd->guest_dmabuf_refresh = false;

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: hppa-firmware.img missing build-id

[Cole Robinson]

On 4/23/24 10:11 AM, Cole Robinson wrote:
> Hi,
> 
> hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
> build-id annotations. rpm builds on Fedora will error if an ELF binary
> doesn't have build-id:
> 
> RPM build errors:
> Missing build-id in
> /tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware.img
> Missing build-id in
> /tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware64.img
> Generating build-id links failed
> 
> I didn't hit this with qemu 8.2.* builds FWIW
> 

Though checking older bundled hppa-firmware binaries with `readelf` I
don't see build-id either, so now I'm not sure why those RPM builds were
passing.

FWIW the RPM check is deep in RPM code:
https://github.com/rpm-software-management/rpm/blob/68d0f3119c3d46b6184f4704edb51749ce9f819e/build/files.c#L1976

Maybe something else in hppa-firmware ELF headers caused this check to
be skipped in the past

Thanks,
Cole

[PATCH v8 2/2] Implement SSH commands in QEMU GA for Windows

[aidan_leuck]

From: aidaleuc 

Signed-off-by: aidaleuc 
---
 qga/commands-windows-ssh.c | 712 +
 qga/commands-windows-ssh.h |  26 ++
 qga/meson.build|   5 +-
 qga/qapi-schema.json   |  17 +-
 4 files changed, 749 insertions(+), 11 deletions(-)
 create mode 100644 qga/commands-windows-ssh.c
 create mode 100644 qga/commands-windows-ssh.h

diff --git a/qga/commands-windows-ssh.c b/qga/commands-windows-ssh.c
new file mode 100644
index 00..6a642e3ba8
--- /dev/null
+++ b/qga/commands-windows-ssh.c
@@ -0,0 +1,712 @@
+/*
+ * QEMU Guest Agent win32-specific command implementations for SSH keys.
+ * The implementation is opinionated and expects the SSH implementation to
+ * be OpenSSH.
+ *
+ * Copyright Schweitzer Engineering Laboratories. 2024
+ *
+ * Authors:
+ *  Aidan Leuck 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include 
+
+#include "commands-common-ssh.h"
+#include "commands-windows-ssh.h"
+#include "guest-agent-core.h"
+#include "limits.h"
+#include "lmaccess.h"
+#include "lmapibuf.h"
+#include "lmerr.h"
+#include "qapi/error.h"
+
+#include "qga-qapi-commands.h"
+#include "sddl.h"
+#include "shlobj.h"
+#include "userenv.h"
+
+#define AUTHORIZED_KEY_FILE "authorized_keys"
+#define AUTHORIZED_KEY_FILE_ADMIN "administrators_authorized_keys"
+#define LOCAL_SYSTEM_SID "S-1-5-18"
+#define ADMIN_SID "S-1-5-32-544"
+
+/*
+ * Frees userInfo structure. This implements the g_auto cleanup
+ * for the structure.
+ */
+void free_userInfo(PWindowsUserInfo info)
+{
+g_free(info->sshDirectory);
+g_free(info->authorizedKeyFile);
+LocalFree(info->SSID);
+g_free(info->username);
+g_free(info);
+}
+
+/*
+ * Gets the admin SSH folder for OpenSSH. OpenSSH does not store
+ * the authorized_key file in the users home directory for security reasons and
+ * instead stores it at %PROGRAMDATA%/ssh. This function returns the path to
+ * that directory on the users machine
+ *
+ * parameters:
+ * errp -> error structure to set when an error occurs
+ * returns: The path to the ssh folder in %PROGRAMDATA% or NULL if an error
+ * occurred.
+ */
+static char *get_admin_ssh_folder(Error **errp)
+{
+/* Allocate memory for the program data path */
+g_autofree char *programDataPath = NULL;
+char *authkeys_path = NULL;
+PWSTR pgDataW = NULL;
+g_autoptr(GError) gerr = NULL;
+
+/* Get the KnownFolderPath on the machine. */
+HRESULT folderResult =
+SHGetKnownFolderPath(&FOLDERID_ProgramData, 0, NULL, &pgDataW);
+if (folderResult != S_OK) {
+error_setg(errp, "Failed to retrieve ProgramData folder");
+return NULL;
+}
+
+/* Convert from a wide string back to a standard character string. */
+programDataPath = g_utf16_to_utf8(pgDataW, -1, NULL, NULL, &gerr);
+CoTaskMemFree(pgDataW);
+if (!programDataPath) {
+error_setg(errp,
+   "Failed converting ProgramData folder path to UTF-16 %s",
+   gerr->message);
+return NULL;
+}
+
+/* Build the path to the file. */
+authkeys_path = g_build_filename(programDataPath, "ssh", NULL);
+return authkeys_path;
+}
+
+/*
+ * Gets the path to the SSH folder for the specified user. If the user is an
+ * admin it returns the ssh folder located at %PROGRAMDATA%/ssh. If the user is
+ * not an admin it returns %USERPROFILE%/.ssh
+ *
+ * parameters:
+ * username -> Username to get the SSH folder for
+ * isAdmin -> Whether the user is an admin or not
+ * errp -> Error structure to set any errors that occur.
+ * returns: path to the ssh folder as a string.
+ */
+static char *get_ssh_folder(const char *username, const bool isAdmin,
+Error **errp)
+{
+DWORD maxSize = MAX_PATH;
+g_autofree char *profilesDir = g_new0(char, maxSize);
+
+if (isAdmin) {
+return get_admin_ssh_folder(errp);
+}
+
+/* If not an Admin the SSH key is in the user directory. */
+/* Get the user profile directory on the machine. */
+BOOL ret = GetProfilesDirectory(profilesDir, &maxSize);
+if (!ret) {
+error_setg_win32(errp, GetLastError(),
+ "failed to retrieve profiles directory");
+return NULL;
+}
+
+/* Builds the filename */
+return g_build_filename(profilesDir, username, ".ssh", NULL);
+}
+
+/*
+ * Creates an entry for the user so they can access the ssh folder in their
+ * userprofile.
+ *
+ * parameters:
+ * userInfo -> Information about the current user
+ * pACL -> Pointer to an ACL structure
+ * errp -> Error structure to set any errors that occur
+ * returns -> 1 on success, 0 otherwise
+ */
+static bool create_acl_user(PWindowsUserInfo userInfo, PACL *pACL, Error 
**errp)
+{
+const int aclSize = 1;
+PACL newACL = NULL;
+EXPLICIT_ACCESS eAccess[1];
+PSID userPSID = NULL;
+
+/* G

[PATCH v8 1/2] Refactor common functions between POSIX and Windows implementation

[aidan_leuck]

From: aidaleuc 

Signed-off-by: aidaleuc 
---
 qga/commands-common-ssh.c | 50 +++
 qga/commands-common-ssh.h | 10 
 qga/commands-posix-ssh.c  | 47 +---
 qga/meson.build   |  1 +
 4 files changed, 62 insertions(+), 46 deletions(-)
 create mode 100644 qga/commands-common-ssh.c
 create mode 100644 qga/commands-common-ssh.h

diff --git a/qga/commands-common-ssh.c b/qga/commands-common-ssh.c
new file mode 100644
index 00..537869fb98
--- /dev/null
+++ b/qga/commands-common-ssh.c
@@ -0,0 +1,50 @@
+/*
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "commands-common-ssh.h"
+
+GStrv read_authkeys(const char *path, Error **errp)
+{
+g_autoptr(GError) err = NULL;
+g_autofree char *contents = NULL;
+
+if (!g_file_get_contents(path, &contents, NULL, &err)) {
+error_setg(errp, "failed to read '%s': %s", path, err->message);
+return NULL;
+}
+
+return g_strsplit(contents, "\n", -1);
+}
+
+bool check_openssh_pub_keys(strList *keys, size_t *nkeys, Error **errp)
+{
+size_t n = 0;
+strList *k;
+
+for (k = keys; k != NULL; k = k->next) {
+if (!check_openssh_pub_key(k->value, errp)) {
+return false;
+}
+n++;
+}
+
+if (nkeys) {
+*nkeys = n;
+}
+return true;
+}
+
+bool check_openssh_pub_key(const char *key, Error **errp)
+{
+/* simple sanity-check, we may want more? */
+if (!key || key[0] == '#' || strchr(key, '\n')) {
+error_setg(errp, "invalid OpenSSH public key: '%s'", key);
+return false;
+}
+
+return true;
+}
diff --git a/qga/commands-common-ssh.h b/qga/commands-common-ssh.h
new file mode 100644
index 00..14d955fa84
--- /dev/null
+++ b/qga/commands-common-ssh.h
@@ -0,0 +1,10 @@
+/*
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qapi/qapi-builtin-types.h"
+
+GStrv read_authkeys(const char *path, Error **errp);
+bool check_openssh_pub_keys(strList *keys, size_t *nkeys, Error **errp);
+bool check_openssh_pub_key(const char *key, Error **errp);
diff --git a/qga/commands-posix-ssh.c b/qga/commands-posix-ssh.c
index 236f80de44..dd2ecb453a 100644
--- a/qga/commands-posix-ssh.c
+++ b/qga/commands-posix-ssh.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 
+#include "commands-common-ssh.h"
 #include "qapi/error.h"
 #include "qga-qapi-commands.h"
 
@@ -80,37 +81,6 @@ mkdir_for_user(const char *path, const struct passwd *p,
 return true;
 }
 
-static bool
-check_openssh_pub_key(const char *key, Error **errp)
-{
-/* simple sanity-check, we may want more? */
-if (!key || key[0] == '#' || strchr(key, '\n')) {
-error_setg(errp, "invalid OpenSSH public key: '%s'", key);
-return false;
-}
-
-return true;
-}
-
-static bool
-check_openssh_pub_keys(strList *keys, size_t *nkeys, Error **errp)
-{
-size_t n = 0;
-strList *k;
-
-for (k = keys; k != NULL; k = k->next) {
-if (!check_openssh_pub_key(k->value, errp)) {
-return false;
-}
-n++;
-}
-
-if (nkeys) {
-*nkeys = n;
-}
-return true;
-}
-
 static bool
 write_authkeys(const char *path, const GStrv keys,
const struct passwd *p, Error **errp)
@@ -139,21 +109,6 @@ write_authkeys(const char *path, const GStrv keys,
 return true;
 }
 
-static GStrv
-read_authkeys(const char *path, Error **errp)
-{
-g_autoptr(GError) err = NULL;
-g_autofree char *contents = NULL;
-
-if (!g_file_get_contents(path, &contents, NULL, &err)) {
-error_setg(errp, "failed to read '%s': %s", path, err->message);
-return NULL;
-}
-
-return g_strsplit(contents, "\n", -1);
-
-}
-
 void
 qmp_guest_ssh_add_authorized_keys(const char *username, strList *keys,
   bool has_reset, bool reset,
diff --git a/qga/meson.build b/qga/meson.build
index 1c3d2a3d1b..4c3899751b 100644
--- a/qga/meson.build
+++ b/qga/meson.build
@@ -66,6 +66,7 @@ qga_ss.add(files(
   'guest-agent-command-state.c',
   'main.c',
   'cutils.c',
+  'commands-common-ssh.c'
 ))
 if host_os == 'windows'
   qga_ss.add(files(
-- 
2.34.1

[PATCH v8 0/2] Implement SSH commands in QEMU GA for Windows

[aidan_leuck]

From: aidaleuc 

This patch aims to implement guest-ssh-add-authorized-keys, 
guest-ssh-remove-authorized-keys, and guest-ssh-get-authorized-keys
for Windows. This PR is based on Microsoft's OpenSSH implementation 
https://github.com/PowerShell/Win32-OpenSSH. The guest agents 
will support Kubevirt and allow guest agent propagation to be used to 
dynamically inject SSH keys. 
https://kubevirt.io/user-guide/virtual_machines/accessing_virtual_machines/#dynamic-ssh-public-key-injection-via-qemu-guest-agent

Changes since v7
* Fixed missing line ending. Thanks IDE. 

Changes since v6
* Fixed issue with file permissions causing public keys to be rejected by the 
SSH server. credit (kkostiuk)
Older versions of OpenSSH such as the one shipped with Windows Server 2022 are 
more stringent on 
file permissions.
* Removed everyone group from create_acl
* Disabled public key file inheritance from the parent folder to control 
permissions in a more granular fashion

Changes since v5
* Fixed spurious formatting 

Changes since v4
* Moved qapi/error.h to commands-common-ssh.c
* Changed  to "qapi/qapi-builtin-types.h" 
* Removed stbool.h from commands-common-ssh.h

Changes since v3
* Renamed commands-ssh-core.c/h to commands-common-ssh.c/h
* Fixed styling errors discovered by checkpatch.pl 
* Moved some header includes to the commands-common-ssh.h

Changes since v2
* Set indent to 4 spaces
* Moved all comments to C style comments
* Fixed a segfault bug in get_user_info function related to non zeroed memory 
when a user did not exist.
* Used g_new0 instead of g_malloc where applicable
* Modified newlines in qapi-schema.json
* Added newlines at the end of all files
* GError functions now use g_autoptr instead of being freed manually.
* Refactored get_ssh_folder to remove goto error statement
* Fixed uninitialized variable pgDataW
* Modified patch order so that the generalization patch is the first patch
* Removed unnecssary ZeroMemory calls

Changes since v1
* Fixed styling errors
* Moved from wcstombs to g_utf functions
* Removed unnecessary if checks on calls to free
* Fixed copyright headers
* Refactored create_acl functions into base function, admin function and user 
function
* Removed unused user count function
* Split up refactor of existing code into a separate patch

aidaleuc (2):
  Refactor common functions between POSIX and Windows implementation
  Implement SSH commands in QEMU GA for Windows

 qga/commands-common-ssh.c  |  50 +++
 qga/commands-common-ssh.h  |  10 +
 qga/commands-posix-ssh.c   |  47 +--
 qga/commands-windows-ssh.c | 712 +
 qga/commands-windows-ssh.h |  26 ++
 qga/meson.build|   6 +-
 qga/qapi-schema.json   |  17 +-
 7 files changed, 811 insertions(+), 57 deletions(-)
 create mode 100644 qga/commands-common-ssh.c
 create mode 100644 qga/commands-common-ssh.h
 create mode 100644 qga/commands-windows-ssh.c
 create mode 100644 qga/commands-windows-ssh.h

-- 
2.34.1

Re: hppa-firmware.img missing build-id

[Richard W.M. Jones]

On Tue, Apr 23, 2024 at 10:11:50AM -0400, Cole Robinson wrote:
> Hi,
> 
> hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
> build-id annotations. rpm builds on Fedora will error if an ELF binary
> doesn't have build-id:
> 
> RPM build errors:
> Missing build-id in
> /tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware.img
> Missing build-id in
> /tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware64.img
> Generating build-id links failed
> 
> I didn't hit this with qemu 8.2.* builds FWIW

Discussed in chat, and I think the consensus is to rebuild these
downstream, since we have the cross-compilers available.  It requires
adding -Wl,--build-id=sha1 at link time.

FWIW this worked for me on Fedora:

# dnf install /usr/bin/hppa-linux-gnu-gcc
$ pushd roms/seabios-hppa
$ make parisc
$ popd

That didn't actually add the .note.gnu.build-id section though, you
have to add this patch:

diff --git a/Makefile.parisc b/Makefile.parisc
index 36edc0c2..3e0c1812 100644
--- a/Makefile.parisc
+++ b/Makefile.parisc
@@ -168,7 +168,7 @@ $(OUT)hppa-firmware$(BIT_SUFFIX).img: $(OUT)autoconf.h 
$(OUT)head.o $(OUT)ccode3
@echo "  Linking $@"
$(Q)$(CPP) $(CPPFLAGS) -Isrc -D__ASSEMBLY__ -DBITS=$(BITS) 
src/parisc/pafirmware.lds.S -o $(OUT)pafirmware.lds
$(Q)$(CC) $(CFLAGS32FLAT) -c src/version.c -o $(OUT)version.o
-   $(Q)$(LD) -N -T $(OUT)pafirmware.lds $(OUT)head.o $(OUT)version.o -X -o 
$@ -e startup --as-needed $(OUT)ccode32flat.o $(LIBGCC)
+   $(Q)$(LD) --build-id=sha1 -N -T $(OUT)pafirmware.lds $(OUT)head.o 
$(OUT)version.o -X -o $@ -e startup --as-needed $(OUT)ccode32flat.o $(LIBGCC)
 
  Kconfig rules
 
... and then:

$ objdump -sj .note.gnu.build-id ./out/hppa-firmware.img 

./out/hppa-firmware.img: file format elf32-big

Contents of section .note.gnu.build-id:
 f000 0004 0014 0003 474e5500  GNU.
 f010 daabe2dc 4e95a4c2 bad0cc57 e7f63152  N..W..1R
 f020 46274585 F'E. 

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

Re: hppa-firmware.img missing build-id

[Helge Deller]

On 4/23/24 16:58, Cole Robinson wrote:

On 4/23/24 10:11 AM, Cole Robinson wrote:

Hi,

hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
build-id annotations. rpm builds on Fedora will error if an ELF binary
doesn't have build-id:

RPM build errors:
 Missing build-id in
/tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware.img
 Missing build-id in
/tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware64.img
 Generating build-id links failed

I didn't hit this with qemu 8.2.* builds FWIW



Though checking older bundled hppa-firmware binaries with `readelf` I
don't see build-id either, so now I'm not sure why those RPM builds were
passing.

FWIW the RPM check is deep in RPM code:
https://github.com/rpm-software-management/rpm/blob/68d0f3119c3d46b6184f4704edb51749ce9f819e/build/files.c#L1976

Maybe something else in hppa-firmware ELF headers caused this check to
be skipped in the past


Maybe Fedora ignores binaries which don't have the executable flag set?
Qemu does not need it.
If so, a "chmod -x pc-bios/hppa-firmware*.img" should be sufficient.


Otherwise, adding "--build-id" to the link line when building the SeaBIOS
hppa-firmware.img does adds a build-id:

diff --git a/Makefile.parisc b/Makefile.parisc
index 5c34eb3d..256142f4 100644
--- a/Makefile.parisc
+++ b/Makefile.parisc
@@ -169,7 +169,7 @@ $(OUT)hppa-firmware$(BIT_SUFFIX).img: $(OUT)autoconf.h 
$(OUT)head.o $(OUT)ccode3
@echo "  Linking $@"
$(Q)$(CPP) $(CPPFLAGS) -Isrc -D__ASSEMBLY__ -DBITS=$(BITS) 
src/parisc/pafirmware.lds.S -o $(OUT)pafirmware.lds
$(Q)$(CC) $(CFLAGS32FLAT) -c src/version.c -o $(OUT)version.o
-   $(Q)$(LD) -N -T $(OUT)pafirmware.lds $(OUT)head.o $(OUT)version.o -X -o 
$@ -e startup --as-needed $(OUT)ccode32flat.o $(LIBGCC)
+   $(Q)$(LD) -N -T $(OUT)pafirmware.lds $(OUT)head.o $(OUT)version.o -X -o 
$@ -e startup --as-needed --build-id $(OUT)ccode32flat.o $(LIBGCC)


deller@carbonx1:/home/cvs/LINUX/seabios$ eu-readelf -n out/hppa-firmware.img

Note section [ 1] '.note.gnu.build-id' of 36 bytes at offset 0x100:
  Owner  Data size  Type
  GNU   20  GNU_BUILD_ID
Build ID: 61a59ebba32fd40eadda7083983a1e1b04ec4082

Are you using the firmware blobs which come with qemu, or do you build 
Seabios-hppa yourself?

Helge

[PULL 00/63] First batch of i386 and build system patch for QEMU 9.1

[Paolo Bonzini]

The following changes since commit 62dbe54c24dbf77051bafe1039c31ddc8f37602d:

  Update version for v9.0.0-rc4 release (2024-04-16 18:06:15 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 254fade7854a6b3d5b7c54a4ca74c25bb928da14:

  target/i386/translate.c: always write 32-bits for SGDT and SIDT (2024-04-23 
16:08:50 +0200)


* cleanups for stubs
* do not link pixman automatically into all targets
* optimize computation of VGA dirty memory region
* kvm: use configs/ definition to conditionalize debug support
* hw: Add compat machines for 9.1
* target/i386: add guest-phys-bits cpu property
* target/i386: Introduce Icelake-Server-v7 and SierraForest models
* target/i386: Export RFDS bit to guests
* q35: SMM ranges cleanups
* target/i386: basic support for confidential guests
* linux-headers: update headers
* target/i386: SEV: use KVM_SEV_INIT2 if possible
* kvm: Introduce support for memory_attributes
* RAMBlock: Add support of KVM private guest memfd
* Consolidate use of warn_report_once()
* pythondeps.toml: warn about updates needed to docs/requirements.txt
* target/i386: always write 32-bits for SGDT and SIDT


Chao Peng (2):
  kvm: Enable KVM_SET_USER_MEMORY_REGION2 for memslot
  kvm: handle KVM_EXIT_MEMORY_FAULT

Gerd Hoffmann (2):
  target/i386: add guest-phys-bits cpu property
  kvm: add support for guest physical bits

Isaku Yamahata (4):
  pci-host/q35: Move PAM initialization above SMRAM initialization
  q35: Introduce smm_ranges property for q35-pci-host
  kvm/tdx: Don't complain when converting vMMIO region to shared
  kvm/tdx: Ignore memory conversion to shared of unassigned region

Mark Cave-Ayland (1):
  target/i386/translate.c: always write 32-bits for SGDT and SIDT

Michael Roth (4):
  scripts/update-linux-headers: Add setup_data.h to import list
  scripts/update-linux-headers: Add bits.h to file imports
  i386/sev: Add 'legacy-vm-type' parameter for SEV guest objects
  hw/i386/sev: Use legacy SEV VM types for older machine types

Paolo Bonzini (28):
  meson: do not link pixman automatically into all targets
  tests: only build plugins if TCG is enabled
  tests/unit: match some unit tests to corresponding feature switches
  yank: only build if needed
  hw/core: Move system emulation files to system_ss
  stubs: remove obsolete stubs
  hw/usb: move stubs out of stubs/
  hw/virtio: move stubs out of stubs/
  semihosting: move stubs out of stubs/
  ramfb: move stubs out of stubs/
  memory-device: move stubs out of stubs/
  colo: move stubs out of stubs/
  stubs: split record/replay stubs further
  stubs: include stubs only if needed
  stubs: move monitor_fdsets_cleanup with other fdset stubs
  vga: optimize computation of dirty memory region
  vga: move dirty memory region code together
  kvm: use configs/ definition to conditionalize debug support
  hw: Add compat machines for 9.1
  linux-headers: update to current kvm/next
  runstate: skip initial CPU reset if reset is not actually possible
  KVM: track whether guest state is encrypted
  KVM: remove kvm_arch_cpu_check_are_resettable
  target/i386: introduce x86-confidential-guest
  target/i386: Implement mc->kvm_type() to get VM type
  target/i386: SEV: use KVM_SEV_INIT2 if possible
  RAMBlock: make guest_memfd require uncoordinated discard
  pythondeps.toml: warn about updates needed to docs/requirements.txt

Pawan Gupta (1):
  target/i386: Export RFDS bit to guests

Philippe Mathieu-Daudé (3):
  ebpf: Restrict to system emulation
  util/qemu-config: Extract QMP commands to qemu-config-qmp.c
  hw: Include minimal source set in user emulation build

Sean Christopherson (1):
  i386/kvm: Move architectural CPUID leaf generation to separate helper

Tao Su (1):
  target/i386: Add new CPU model SierraForest

Xiaoyao Li (11):
  hw/i386/acpi: Set PCAT_COMPAT bit only when pic is not disabled
  confidential guest support: Add kvm_init() and kvm_reset() in class
  i386/sev: Switch to use confidential_guest_kvm_init()
  ppc/pef: switch to use confidential_guest_kvm_init/reset()
  s390: Switch to use confidential_guest_kvm_init()
  trace/kvm: Split address space and slot id in trace_kvm_set_user_memory()
  kvm: Introduce support for memory_attributes
  RAMBlock: Add support of KVM private guest memfd
  kvm/memory: Make memory type private by default if it has guest memfd 
backend
  HostMem: Add mechanism to opt in kvm guest memfd via MachineState
  physmem: Introduce ram_block_discard_guest_memfd_range()

Zhao Liu (4):
  target/i386/host-cpu: Consolidate the use of warn_report_once()
  target/i386/cpu: Cons

[PULL 02/63] tests: only build plugins if TCG is enabled

[Paolo Bonzini]

There is no way to use them for testing, if all the available
accelerators use hardware virtualization.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-ID: <20240408155330.522792-3-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 tests/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/meson.build b/tests/meson.build
index 0a6f96f8f84..acb6807094b 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -78,9 +78,9 @@ subdir('decode')
 
 if 'CONFIG_TCG' in config_all_accel
   subdir('fp')
+  subdir('plugin')
 endif
 
-subdir('plugin')
 subdir('unit')
 subdir('qapi-schema')
 subdir('qtest')
-- 
2.44.0

[PULL 01/63] meson: do not link pixman automatically into all targets

[Paolo Bonzini]

The dependency on pixman is listed manually in all sourcesets that need it.
There is no need to bring into libqemuutil, since there is nothing in
util/ that needs pixman either.

Reported-by: Michael Tokarev 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Message-ID: <20240408155330.522792-2-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 91a0aa64c64..8c1271b8846 100644
--- a/meson.build
+++ b/meson.build
@@ -3481,7 +3481,7 @@ util_ss = util_ss.apply({})
 libqemuutil = static_library('qemuutil',
  build_by_default: false,
  sources: util_ss.sources() + stub_ss.sources() + 
genh,
- dependencies: [util_ss.dependencies(), libm, 
threads, glib, socket, malloc, pixman])
+ dependencies: [util_ss.dependencies(), libm, 
threads, glib, socket, malloc])
 qemuutil = declare_dependency(link_with: libqemuutil,
   sources: genh + version_res,
   dependencies: [event_loop_base])
-- 
2.44.0

[PULL 10/63] hw/usb: move stubs out of stubs/

[Paolo Bonzini]

Since the USB stubs are needed exactly when the Kconfig symbols are not
enabled, they can be placed in hw/usb/ and conditionalized on CONFIG_USB.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-ID: <20240408155330.522792-11-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 stubs/usb-dev-stub.c => hw/usb/bus-stub.c | 0
 hw/usb/meson.build| 2 +-
 stubs/meson.build | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)
 rename stubs/usb-dev-stub.c => hw/usb/bus-stub.c (100%)

diff --git a/stubs/usb-dev-stub.c b/hw/usb/bus-stub.c
similarity index 100%
rename from stubs/usb-dev-stub.c
rename to hw/usb/bus-stub.c
diff --git a/hw/usb/meson.build b/hw/usb/meson.build
index aac3bb35f27..23f7f7acb50 100644
--- a/hw/usb/meson.build
+++ b/hw/usb/meson.build
@@ -9,7 +9,7 @@ system_ss.add(when: 'CONFIG_USB', if_true: files(
   'desc-msos.c',
   'libhw.c',
   'pcap.c',
-))
+), if_false: files('bus-stub.c'))
 
 # usb host adapters
 system_ss.add(when: 'CONFIG_USB_UHCI', if_true: files('hcd-uhci.c'))
diff --git a/stubs/meson.build b/stubs/meson.build
index aa7120f7110..45616afbfaa 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -56,7 +56,6 @@ endif
 if have_system
   stub_ss.add(files('fw_cfg.c'))
   stub_ss.add(files('semihost.c'))
-  stub_ss.add(files('usb-dev-stub.c'))
   stub_ss.add(files('xen-hw-stub.c'))
   stub_ss.add(files('virtio-md-pci.c'))
 else
-- 
2.44.0

[PULL 17/63] stubs: include stubs only if needed

[Paolo Bonzini]

Currently it is not documented anywhere why some functions need to
be stubbed.

Group the files in stubs/meson.build according to who needs them, both
to reduce the size of the compilation and to clarify the use of stubs.

Signed-off-by: Paolo Bonzini 
Message-ID: <20240408155330.522792-18-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 stubs/{monitor.c => monitor-internal.c} |   0
 stubs/meson.build   | 122 +++-
 2 files changed, 75 insertions(+), 47 deletions(-)
 rename stubs/{monitor.c => monitor-internal.c} (100%)

diff --git a/stubs/monitor.c b/stubs/monitor-internal.c
similarity index 100%
rename from stubs/monitor.c
rename to stubs/monitor-internal.c
diff --git a/stubs/meson.build b/stubs/meson.build
index 4a524f5816b..8ee1fd57530 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -1,58 +1,86 @@
-stub_ss.add(files('bdrv-next-monitor-owned.c'))
-stub_ss.add(files('blk-commit-all.c'))
-stub_ss.add(files('blk-exp-close-all.c'))
-stub_ss.add(files('blockdev-close-all-bdrv-states.c'))
-stub_ss.add(files('change-state-handler.c'))
-stub_ss.add(files('cmos.c'))
+# If possible, add new files to other directories, by using "if_false".
+# If you need them here, try to add them under one of the if statements
+# below, so that it is clear who needs the stubbed functionality.
+
 stub_ss.add(files('cpu-get-clock.c'))
-stub_ss.add(files('cpus-get-virtual-clock.c'))
-stub_ss.add(files('qemu-timer-notify-cb.c'))
-stub_ss.add(files('icount.c'))
-stub_ss.add(files('dump.c'))
-stub_ss.add(files('error-printf.c'))
 stub_ss.add(files('fdset.c'))
-stub_ss.add(files('gdbstub.c'))
-stub_ss.add(files('get-vm-name.c'))
-stub_ss.add(files('graph-lock.c'))
-stub_ss.add(files('hotplug-stubs.c'))
-if linux_io_uring.found()
-  stub_ss.add(files('io_uring.c'))
-endif
 stub_ss.add(files('iothread-lock.c'))
-if have_block
-  stub_ss.add(files('iothread-lock-block.c'))
-endif
 stub_ss.add(files('is-daemonized.c'))
-if libaio.found()
-  stub_ss.add(files('linux-aio.c'))
-endif
-stub_ss.add(files('migr-blocker.c'))
-stub_ss.add(files('monitor.c'))
 stub_ss.add(files('monitor-core.c'))
-stub_ss.add(files('physmem.c'))
-stub_ss.add(files('qemu-timer-notify-cb.c'))
-stub_ss.add(files('qmp-command-available.c'))
-stub_ss.add(files('qmp-quit.c'))
-stub_ss.add(files('qtest.c'))
-stub_ss.add(files('ram-block.c'))
-stub_ss.add(files('replay.c'))
 stub_ss.add(files('replay-mode.c'))
-stub_ss.add(files('runstate-check.c'))
-stub_ss.add(files('sysbus.c'))
-stub_ss.add(files('target-get-monitor-def.c'))
-stub_ss.add(files('target-monitor-defs.c'))
 stub_ss.add(files('trace-control.c'))
-stub_ss.add(files('uuid.c'))
-stub_ss.add(files('vmstate.c'))
-stub_ss.add(files('vm-stop.c'))
-stub_ss.add(files('win32-kbd-hook.c'))
-stub_ss.add(files('cpu-synchronize-state.c'))
-if have_block or have_ga
+
+if have_block
+  stub_ss.add(files('bdrv-next-monitor-owned.c'))
+  stub_ss.add(files('blk-commit-all.c'))
+  stub_ss.add(files('blk-exp-close-all.c'))
+  stub_ss.add(files('blockdev-close-all-bdrv-states.c'))
+  stub_ss.add(files('change-state-handler.c'))
+  stub_ss.add(files('get-vm-name.c'))
+  stub_ss.add(files('iothread-lock-block.c'))
+  stub_ss.add(files('migr-blocker.c'))
+  stub_ss.add(files('physmem.c'))
+  stub_ss.add(files('ram-block.c'))
   stub_ss.add(files('replay-tools.c'))
+  stub_ss.add(files('runstate-check.c'))
+  stub_ss.add(files('uuid.c'))
 endif
-if have_system
-  stub_ss.add(files('fw_cfg.c'))
-  stub_ss.add(files('xen-hw-stub.c'))
-else
+
+if have_block or have_ga
+  # stubs for hooks in util/main-loop.c, util/async.c etc.
+  stub_ss.add(files('cpus-get-virtual-clock.c'))
+  stub_ss.add(files('icount.c'))
+  stub_ss.add(files('graph-lock.c'))
+  if linux_io_uring.found()
+stub_ss.add(files('io_uring.c'))
+  endif
+  if libaio.found()
+stub_ss.add(files('linux-aio.c'))
+  endif
+  stub_ss.add(files('qemu-timer-notify-cb.c'))
+
+  # stubs for monitor
+  stub_ss.add(files('monitor-internal.c'))
+  stub_ss.add(files('qmp-command-available.c'))
+  stub_ss.add(files('qmp-quit.c'))
+endif
+
+if have_block or have_user
+  stub_ss.add(files('qtest.c'))
+  stub_ss.add(files('vm-stop.c'))
+  stub_ss.add(files('vmstate.c'))
+
+  # more symbols provided by the monitor
+  stub_ss.add(files('error-printf.c'))
+endif
+
+if have_user
+  # Symbols that are used by hw/core.
+  stub_ss.add(files('cpu-synchronize-state.c'))
   stub_ss.add(files('qdev.c'))
 endif
+
+if have_system
+  # Symbols that are only needed in some configurations.  Try not
+  # adding more of these.  If the symbol is used in specific_ss,
+  # in particular, consider defining a preprocessor macro via
+  # Kconfig or configs/targets/.
+  stub_ss.add(files('dump.c'))
+  stub_ss.add(files('cmos.c'))
+  stub_ss.add(files('fw_cfg.c'))
+  stub_ss.add(files('target-get-monitor-def.c'))
+  stub_ss.add(files('target-monitor-defs.c'))
+  stub_ss.add(files('win32-kbd-hook.c'))
+  stub_ss.add(files('xen-hw-stub.c'))
+endif
+
+if ha

[PULL 04/63] tests/unit: match some unit tests to corresponding feature switches

[Paolo Bonzini]

Try not to test code that is not used by user mode emulation, or by the
block layer, unless they are being compiled; and fix test-timed-average
which was not compiled with --disable-system --enable-tools.

This is by no means complete, it only touches the more blatantly
wrong cases.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Message-ID: <20240408155330.522792-5-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 tests/unit/meson.build | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/unit/meson.build b/tests/unit/meson.build
index 228a21d03c2..26c109c968c 100644
--- a/tests/unit/meson.build
+++ b/tests/unit/meson.build
@@ -18,7 +18,6 @@ tests = {
   'test-forward-visitor': [testqapi],
   'test-string-input-visitor': [testqapi],
   'test-string-output-visitor': [testqapi],
-  'test-opts-visitor': [testqapi],
   'test-visitor-serialization': [testqapi],
   'test-bitmap': [],
   'test-resv-mem': [],
@@ -46,12 +45,8 @@ tests = {
   'test-qemu-opts': [],
   'test-keyval': [testqapi],
   'test-logging': [],
-  'test-uuid': [],
-  'ptimer-test': ['ptimer-test-stubs.c', meson.project_source_root() / 
'hw/core/ptimer.c'],
   'test-qapi-util': [],
   'test-interval-tree': [],
-  'test-xs-node': [qom],
-  'test-virtio-dmabuf': [meson.project_source_root() / 
'hw/display/virtio-dmabuf.c'],
 }
 
 if have_system or have_tools
@@ -97,6 +92,8 @@ if have_block
 'test-crypto-ivgen': [io],
 'test-crypto-afsplit': [io],
 'test-crypto-block': [io],
+'test-timed-average': [],
+'test-uuid': [],
   }
   if gnutls.found() and \
  tasn1.found() and \
@@ -131,10 +128,13 @@ endif
 
 if have_system
   tests += {
+'ptimer-test': ['ptimer-test-stubs.c', meson.project_source_root() / 
'hw/core/ptimer.c'],
 'test-iov': [],
+'test-opts-visitor': [testqapi],
+'test-xs-node': [qom],
+'test-virtio-dmabuf': [meson.project_source_root() / 
'hw/display/virtio-dmabuf.c'],
 'test-qmp-cmds': [testqapi],
 'test-xbzrle': [migration],
-'test-timed-average': [],
 'test-util-sockets': ['socket-helpers.c'],
 'test-base64': [],
 'test-bufferiszero': [],
-- 
2.44.0

[PULL 21/63] kvm: use configs/ definition to conditionalize debug support

[Paolo Bonzini]

If an architecture adds support for KVM_CAP_SET_GUEST_DEBUG but QEMU does not
have the necessary code, QEMU will fail to build after updating kernel headers.
Avoid this by using a #define in config-target.h instead of 
KVM_CAP_SET_GUEST_DEBUG.

Signed-off-by: Paolo Bonzini 
---
 configs/targets/aarch64-softmmu.mak |  1 +
 configs/targets/i386-softmmu.mak|  1 +
 configs/targets/ppc-softmmu.mak |  1 +
 configs/targets/ppc64-softmmu.mak   |  1 +
 configs/targets/s390x-softmmu.mak   |  1 +
 configs/targets/x86_64-softmmu.mak  |  1 +
 include/sysemu/kvm.h|  2 +-
 include/sysemu/kvm_int.h|  2 +-
 accel/kvm/kvm-accel-ops.c   |  4 ++--
 accel/kvm/kvm-all.c | 10 +-
 10 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/configs/targets/aarch64-softmmu.mak 
b/configs/targets/aarch64-softmmu.mak
index b4338e95680..83c22391a69 100644
--- a/configs/targets/aarch64-softmmu.mak
+++ b/configs/targets/aarch64-softmmu.mak
@@ -1,5 +1,6 @@
 TARGET_ARCH=aarch64
 TARGET_BASE_ARCH=arm
 TARGET_SUPPORTS_MTTCG=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml 
gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml gdb-xml/arm-vfp3.xml 
gdb-xml/arm-vfp-sysregs.xml gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml 
gdb-xml/arm-m-profile-mve.xml gdb-xml/aarch64-pauth.xml
 TARGET_NEED_FDT=y
diff --git a/configs/targets/i386-softmmu.mak b/configs/targets/i386-softmmu.mak
index 6b3c99fc86c..d61b5076134 100644
--- a/configs/targets/i386-softmmu.mak
+++ b/configs/targets/i386-softmmu.mak
@@ -1,4 +1,5 @@
 TARGET_ARCH=i386
 TARGET_SUPPORTS_MTTCG=y
 TARGET_NEED_FDT=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/i386-32bit.xml
diff --git a/configs/targets/ppc-softmmu.mak b/configs/targets/ppc-softmmu.mak
index 774440108f7..f3ea9c98f75 100644
--- a/configs/targets/ppc-softmmu.mak
+++ b/configs/targets/ppc-softmmu.mak
@@ -1,4 +1,5 @@
 TARGET_ARCH=ppc
 TARGET_BIG_ENDIAN=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/power-core.xml gdb-xml/power-fpu.xml 
gdb-xml/power-altivec.xml gdb-xml/power-spe.xml
 TARGET_NEED_FDT=y
diff --git a/configs/targets/ppc64-softmmu.mak 
b/configs/targets/ppc64-softmmu.mak
index ddf0c39617f..1db8d8381d0 100644
--- a/configs/targets/ppc64-softmmu.mak
+++ b/configs/targets/ppc64-softmmu.mak
@@ -2,5 +2,6 @@ TARGET_ARCH=ppc64
 TARGET_BASE_ARCH=ppc
 TARGET_BIG_ENDIAN=y
 TARGET_SUPPORTS_MTTCG=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/power64-core.xml gdb-xml/power-fpu.xml 
gdb-xml/power-altivec.xml gdb-xml/power-spe.xml gdb-xml/power-vsx.xml
 TARGET_NEED_FDT=y
diff --git a/configs/targets/s390x-softmmu.mak 
b/configs/targets/s390x-softmmu.mak
index 70d2f9f0ba0..b22218aacc8 100644
--- a/configs/targets/s390x-softmmu.mak
+++ b/configs/targets/s390x-softmmu.mak
@@ -1,4 +1,5 @@
 TARGET_ARCH=s390x
 TARGET_BIG_ENDIAN=y
 TARGET_SUPPORTS_MTTCG=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/s390x-core64.xml gdb-xml/s390-acr.xml 
gdb-xml/s390-fpr.xml gdb-xml/s390-vx.xml gdb-xml/s390-cr.xml 
gdb-xml/s390-virt.xml gdb-xml/s390-virt-kvm.xml gdb-xml/s390-gs.xml
diff --git a/configs/targets/x86_64-softmmu.mak 
b/configs/targets/x86_64-softmmu.mak
index 197817c9434..c5f882e5ba1 100644
--- a/configs/targets/x86_64-softmmu.mak
+++ b/configs/targets/x86_64-softmmu.mak
@@ -2,4 +2,5 @@ TARGET_ARCH=x86_64
 TARGET_BASE_ARCH=i386
 TARGET_SUPPORTS_MTTCG=y
 TARGET_NEED_FDT=y
+TARGET_KVM_HAVE_GUEST_DEBUG=y
 TARGET_XML_FILES= gdb-xml/i386-64bit.xml
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index fad9a7e8ff3..2cba899270c 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -224,7 +224,7 @@ void kvm_flush_coalesced_mmio_buffer(void);
  * calling down to kvm_arch_update_guest_debug after the generic
  * fields have been set.
  */
-#ifdef KVM_CAP_SET_GUEST_DEBUG
+#ifdef TARGET_KVM_HAVE_GUEST_DEBUG
 int kvm_update_guest_debug(CPUState *cpu, unsigned long reinject_trap);
 #else
 static inline int kvm_update_guest_debug(CPUState *cpu, unsigned long 
reinject_trap)
diff --git a/include/sysemu/kvm_int.h b/include/sysemu/kvm_int.h
index 882e37e12c5..94488d2c1a2 100644
--- a/include/sysemu/kvm_int.h
+++ b/include/sysemu/kvm_int.h
@@ -78,7 +78,7 @@ struct KVMState
 struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;
 bool coalesced_flush_in_progress;
 int vcpu_events;
-#ifdef KVM_CAP_SET_GUEST_DEBUG
+#ifdef TARGET_KVM_HAVE_GUEST_DEBUG
 QTAILQ_HEAD(, kvm_sw_breakpoint) kvm_sw_breakpoints;
 #endif
 int max_nested_state_len;
diff --git a/accel/kvm/kvm-accel-ops.c b/accel/kvm/kvm-accel-ops.c
index b3c946dc4b4..f5ac643fca3 100644
--- a/accel/kvm/kvm-accel-ops.c
+++ b/accel/kvm/kvm-accel-ops.c
@@ -85,7 +85,7 @@ static bool kvm_cpus_are_resettable(void)
 return !kvm_enabled() || kvm_cpu_check_are_resettable();
 }
 
-#ifdef KVM_CAP_SET_GUEST_DEBUG
+#ifdef TARGET_KVM_HAVE_GUEST_DEBUG
 static int kvm_update_guest_debug_ops(CPUState *cpu)
 {
 return kvm_

[PULL 50/63] kvm: Enable KVM_SET_USER_MEMORY_REGION2 for memslot

[Paolo Bonzini]

From: Chao Peng 

Switch to KVM_SET_USER_MEMORY_REGION2 when supported by KVM.

With KVM_SET_USER_MEMORY_REGION2, QEMU can set up memory region that
backend'ed both by hva-based shared memory and guest memfd based private
memory.

Signed-off-by: Chao Peng 
Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Message-ID: <20240320083945.991426-10-michael.r...@amd.com>
Signed-off-by: Paolo Bonzini 
---
 include/sysemu/kvm_int.h |  2 ++
 accel/kvm/kvm-all.c  | 46 +---
 accel/kvm/trace-events   |  2 +-
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/include/sysemu/kvm_int.h b/include/sysemu/kvm_int.h
index 227b61fec3d..3f3d13f8166 100644
--- a/include/sysemu/kvm_int.h
+++ b/include/sysemu/kvm_int.h
@@ -30,6 +30,8 @@ typedef struct KVMSlot
 int as_id;
 /* Cache of the offset in ram address space */
 ram_addr_t ram_start_offset;
+int guest_memfd;
+hwaddr guest_memfd_offset;
 } KVMSlot;
 
 typedef struct KVMMemoryUpdate {
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 1b7bbd838c4..0386d4901fa 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -284,35 +284,58 @@ int kvm_physical_memory_addr_from_host(KVMState *s, void 
*ram,
 static int kvm_set_user_memory_region(KVMMemoryListener *kml, KVMSlot *slot, 
bool new)
 {
 KVMState *s = kvm_state;
-struct kvm_userspace_memory_region mem;
+struct kvm_userspace_memory_region2 mem;
 int ret;
 
 mem.slot = slot->slot | (kml->as_id << 16);
 mem.guest_phys_addr = slot->start_addr;
 mem.userspace_addr = (unsigned long)slot->ram;
 mem.flags = slot->flags;
+mem.guest_memfd = slot->guest_memfd;
+mem.guest_memfd_offset = slot->guest_memfd_offset;
 
 if (slot->memory_size && !new && (mem.flags ^ slot->old_flags) & 
KVM_MEM_READONLY) {
 /* Set the slot size to 0 before setting the slot to the desired
  * value. This is needed based on KVM commit 75d61fbc. */
 mem.memory_size = 0;
-ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
+
+if (kvm_guest_memfd_supported) {
+ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION2, &mem);
+} else {
+ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
+}
 if (ret < 0) {
 goto err;
 }
 }
 mem.memory_size = slot->memory_size;
-ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
+if (kvm_guest_memfd_supported) {
+ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION2, &mem);
+} else {
+ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
+}
 slot->old_flags = mem.flags;
 err:
 trace_kvm_set_user_memory(mem.slot >> 16, (uint16_t)mem.slot, mem.flags,
   mem.guest_phys_addr, mem.memory_size,
-  mem.userspace_addr, ret);
+  mem.userspace_addr, mem.guest_memfd,
+  mem.guest_memfd_offset, ret);
 if (ret < 0) {
-error_report("%s: KVM_SET_USER_MEMORY_REGION failed, slot=%d,"
- " start=0x%" PRIx64 ", size=0x%" PRIx64 ": %s",
- __func__, mem.slot, slot->start_addr,
- (uint64_t)mem.memory_size, strerror(errno));
+if (kvm_guest_memfd_supported) {
+error_report("%s: KVM_SET_USER_MEMORY_REGION2 failed, slot=%d,"
+" start=0x%" PRIx64 ", size=0x%" PRIx64 ","
+" flags=0x%" PRIx32 ", guest_memfd=%" PRId32 ","
+" guest_memfd_offset=0x%" PRIx64 ": %s",
+__func__, mem.slot, slot->start_addr,
+(uint64_t)mem.memory_size, mem.flags,
+mem.guest_memfd, (uint64_t)mem.guest_memfd_offset,
+strerror(errno));
+} else {
+error_report("%s: KVM_SET_USER_MEMORY_REGION failed, slot=%d,"
+" start=0x%" PRIx64 ", size=0x%" PRIx64 ": %s",
+__func__, mem.slot, slot->start_addr,
+(uint64_t)mem.memory_size, strerror(errno));
+}
 }
 return ret;
 }
@@ -467,6 +490,10 @@ static int kvm_mem_flags(MemoryRegion *mr)
 if (readonly && kvm_readonly_mem_allowed) {
 flags |= KVM_MEM_READONLY;
 }
+if (memory_region_has_guest_memfd(mr)) {
+assert(kvm_guest_memfd_supported);
+flags |= KVM_MEM_GUEST_MEMFD;
+}
 return flags;
 }
 
@@ -1394,6 +1421,9 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
 mem->ram_start_offset = ram_start_offset;
 mem->ram = ram;
 mem->flags = kvm_mem_flags(mr);
+mem->guest_memfd = mr->ram_block->guest_memfd;
+mem->guest_memfd_offset = (uint8_t*)ram - mr->ram_block->host;
+
 kvm_slot_init_dirty_bitmap(mem);
 err = kvm_set_user_memory_region(kml, mem, true);
 if (err) {

[PULL 30/63] q35: Introduce smm_ranges property for q35-pci-host

[Paolo Bonzini]

From: Isaku Yamahata 

Add a q35 property to check whether or not SMM ranges, e.g. SMRAM, TSEG,
etc... exist for the target platform.  TDX doesn't support SMM and doesn't
play nice with QEMU modifying related guest memory ranges.

Signed-off-by: Isaku Yamahata 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Michael Roth 
Message-ID: <20240320083945.991426-19-michael.r...@amd.com>
Signed-off-by: Paolo Bonzini 
---
 include/hw/i386/pc.h  |  1 +
 include/hw/pci-host/q35.h |  1 +
 hw/i386/pc_q35.c  |  2 ++
 hw/pci-host/q35.c | 42 +++
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 349f79df086..e52290916cb 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -161,6 +161,7 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int 
level);
 #define PCI_HOST_PROP_PCI_HOLE64_SIZE  "pci-hole64-size"
 #define PCI_HOST_BELOW_4G_MEM_SIZE "below-4g-mem-size"
 #define PCI_HOST_ABOVE_4G_MEM_SIZE "above-4g-mem-size"
+#define PCI_HOST_PROP_SMM_RANGES   "smm-ranges"
 
 
 void pc_pci_as_mapping_init(MemoryRegion *system_memory,
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index bafcbe67521..22fadfa3ed7 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -50,6 +50,7 @@ struct MCHPCIState {
 MemoryRegion tseg_blackhole, tseg_window;
 MemoryRegion smbase_blackhole, smbase_window;
 bool has_smram_at_smbase;
+bool has_smm_ranges;
 Range pci_hole;
 uint64_t below_4g_mem_size;
 uint64_t above_4g_mem_size;
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 6e1180d4b60..bb53a51ac18 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -219,6 +219,8 @@ static void pc_q35_init(MachineState *machine)
 x86ms->above_4g_mem_size, NULL);
 object_property_set_bool(phb, PCI_HOST_BYPASS_IOMMU,
  pcms->default_bus_bypass_iommu, NULL);
+object_property_set_bool(phb, PCI_HOST_PROP_SMM_RANGES,
+ x86_machine_is_smm_enabled(x86ms), NULL);
 sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
 
 /* pci */
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 98d4a7c253a..0b6cbaed7ed 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -179,6 +179,8 @@ static Property q35_host_props[] = {
  mch.below_4g_mem_size, 0),
 DEFINE_PROP_SIZE(PCI_HOST_ABOVE_4G_MEM_SIZE, Q35PCIHost,
  mch.above_4g_mem_size, 0),
+DEFINE_PROP_BOOL(PCI_HOST_PROP_SMM_RANGES, Q35PCIHost,
+ mch.has_smm_ranges, true),
 DEFINE_PROP_BOOL("x-pci-hole64-fix", Q35PCIHost, pci_hole64_fix, true),
 DEFINE_PROP_END_OF_LIST(),
 };
@@ -214,6 +216,7 @@ static void q35_host_initfn(Object *obj)
 /* mch's object_initialize resets the default value, set it again */
 qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE,
  Q35_PCI_HOST_HOLE64_SIZE_DEFAULT);
+
 object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
 q35_host_get_pci_hole_start,
 NULL, NULL, NULL);
@@ -476,6 +479,10 @@ static void mch_write_config(PCIDevice *d,
 mch_update_pciexbar(mch);
 }
 
+if (!mch->has_smm_ranges) {
+return;
+}
+
 if (ranges_overlap(address, len, MCH_HOST_BRIDGE_SMRAM,
MCH_HOST_BRIDGE_SMRAM_SIZE)) {
 mch_update_smram(mch);
@@ -494,10 +501,13 @@ static void mch_write_config(PCIDevice *d,
 static void mch_update(MCHPCIState *mch)
 {
 mch_update_pciexbar(mch);
+
 mch_update_pam(mch);
-mch_update_smram(mch);
-mch_update_ext_tseg_mbytes(mch);
-mch_update_smbase_smram(mch);
+if (mch->has_smm_ranges) {
+mch_update_smram(mch);
+mch_update_ext_tseg_mbytes(mch);
+mch_update_smbase_smram(mch);
+}
 
 /*
  * pci hole goes from end-of-low-ram to io-apic.
@@ -538,19 +548,21 @@ static void mch_reset(DeviceState *qdev)
 pci_set_quad(d->config + MCH_HOST_BRIDGE_PCIEXBAR,
  MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT);
 
-d->config[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_DEFAULT;
-d->config[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_DEFAULT;
-d->wmask[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_WMASK;
-d->wmask[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_WMASK;
+if (mch->has_smm_ranges) {
+d->config[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_DEFAULT;
+d->config[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_DEFAULT;
+d->wmask[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_WMASK;
+d->wmask[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_WMASK;
 
-if (mch->ext_tseg_mbytes > 0) {
-pci_set_word(d->config + MCH_HOST_BRIDGE_EXT_TSEG_MB

[PULL 56/63] kvm/tdx: Don't complain when converting vMMIO region to shared

[Paolo Bonzini]

From: Isaku Yamahata 

Because vMMIO region needs to be shared region, guest TD may explicitly
convert such region from private to shared.  Don't complain such
conversion.

Signed-off-by: Isaku Yamahata 
Signed-off-by: Xiaoyao Li 
Message-ID: <20240229063726.610065-34-xiaoyao...@intel.com>
Signed-off-by: Paolo Bonzini 
---
 accel/kvm/kvm-all.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 9eef2c64003..0911154bf8e 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2927,9 +2927,22 @@ int kvm_convert_memory(hwaddr start, hwaddr size, bool 
to_private)
 }
 
 if (!memory_region_has_guest_memfd(mr)) {
-error_report("Converting non guest_memfd backed memory region "
- "(0x%"HWADDR_PRIx" ,+ 0x%"HWADDR_PRIx") to %s",
- start, size, to_private ? "private" : "shared");
+/*
+ * Because vMMIO region must be shared, guest TD may convert vMMIO
+ * region to shared explicitly.  Don't complain such case.  See
+ * memory_region_type() for checking if the region is MMIO region.
+ */
+if (!to_private &&
+!memory_region_is_ram(mr) &&
+!memory_region_is_ram_device(mr) &&
+!memory_region_is_rom(mr) &&
+!memory_region_is_romd(mr)) {
+   ret = 0;
+} else {
+error_report("Convert non guest_memfd backed memory region "
+"(0x%"HWADDR_PRIx" ,+ 0x%"HWADDR_PRIx") to %s",
+start, size, to_private ? "private" : "shared");
+}
 goto out_unref;
 }
 
-- 
2.44.0

[PULL 57/63] kvm/tdx: Ignore memory conversion to shared of unassigned region

[Paolo Bonzini]

From: Isaku Yamahata 

TDX requires vMMIO region to be shared.  For KVM, MMIO region is the region
which kvm memslot isn't assigned to (except in-kernel emulation).
qemu has the memory region for vMMIO at each device level.

While OVMF issues MapGPA(to-shared) conservatively on 32bit PCI MMIO
region, qemu doesn't find corresponding vMMIO region because it's before
PCI device allocation and memory_region_find() finds the device region, not
PCI bus region.  It's safe to ignore MapGPA(to-shared) because when guest
accesses those region they use GPA with shared bit set for vMMIO.  Ignore
memory conversion request of non-assigned region to shared and return
success.  Otherwise OVMF is confused and panics there.

Signed-off-by: Isaku Yamahata 
Signed-off-by: Xiaoyao Li 
Message-ID: <20240229063726.610065-35-xiaoyao...@intel.com>
Signed-off-by: Paolo Bonzini 
---
 accel/kvm/kvm-all.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 0911154bf8e..d7281b93f3b 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2923,6 +2923,18 @@ int kvm_convert_memory(hwaddr start, hwaddr size, bool 
to_private)
 section = memory_region_find(get_system_memory(), start, size);
 mr = section.mr;
 if (!mr) {
+/*
+ * Ignore converting non-assigned region to shared.
+ *
+ * TDX requires vMMIO region to be shared to inject #VE to guest.
+ * OVMF issues conservatively MapGPA(shared) on 32bit PCI MMIO region,
+ * and vIO-APIC 0xFEC0 4K page.
+ * OVMF assigns 32bit PCI MMIO region to
+ * [top of low memory: typically 2GB=0xC00,  0xFC0)
+ */
+if (!to_private) {
+return 0;
+}
 return -1;
 }
 
-- 
2.44.0

[PULL 34/63] ppc/pef: switch to use confidential_guest_kvm_init/reset()

[Paolo Bonzini]

From: Xiaoyao Li 

Use the unified interface to call confidential guest related kvm_init()
and kvm_reset(), to avoid exposing pef specific functions.

As a bonus, pef.h goes away since there is no direct call from sPAPR
board code to PEF code anymore.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Paolo Bonzini 
---
 include/hw/ppc/pef.h | 17 -
 hw/ppc/pef.c |  9 ++---
 hw/ppc/spapr.c   | 10 +++---
 3 files changed, 13 insertions(+), 23 deletions(-)
 delete mode 100644 include/hw/ppc/pef.h

diff --git a/include/hw/ppc/pef.h b/include/hw/ppc/pef.h
deleted file mode 100644
index 707dbe524c4..000
--- a/include/hw/ppc/pef.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * PEF (Protected Execution Facility) for POWER support
- *
- * Copyright Red Hat.
- *
- * This work is licensed under the terms of the GNU GPL, version 2 or later.
- * See the COPYING file in the top-level directory.
- *
- */
-
-#ifndef HW_PPC_PEF_H
-#define HW_PPC_PEF_H
-
-int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp);
-int pef_kvm_reset(ConfidentialGuestSupport *cgs, Error **errp);
-
-#endif /* HW_PPC_PEF_H */
diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
index d28ed3ba733..47553348b1e 100644
--- a/hw/ppc/pef.c
+++ b/hw/ppc/pef.c
@@ -15,7 +15,6 @@
 #include "sysemu/kvm.h"
 #include "migration/blocker.h"
 #include "exec/confidential-guest-support.h"
-#include "hw/ppc/pef.h"
 
 #define TYPE_PEF_GUEST "pef-guest"
 OBJECT_DECLARE_SIMPLE_TYPE(PefGuest, PEF_GUEST)
@@ -93,7 +92,7 @@ static int kvmppc_svm_off(Error **errp)
 #endif
 }
 
-int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
+static int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
 if (!object_dynamic_cast(OBJECT(cgs), TYPE_PEF_GUEST)) {
 return 0;
@@ -107,7 +106,7 @@ int pef_kvm_init(ConfidentialGuestSupport *cgs, Error 
**errp)
 return kvmppc_svm_init(cgs, errp);
 }
 
-int pef_kvm_reset(ConfidentialGuestSupport *cgs, Error **errp)
+static int pef_kvm_reset(ConfidentialGuestSupport *cgs, Error **errp)
 {
 if (!object_dynamic_cast(OBJECT(cgs), TYPE_PEF_GUEST)) {
 return 0;
@@ -131,6 +130,10 @@ OBJECT_DEFINE_TYPE_WITH_INTERFACES(PefGuest,
 
 static void pef_guest_class_init(ObjectClass *oc, void *data)
 {
+ConfidentialGuestSupportClass *klass = 
CONFIDENTIAL_GUEST_SUPPORT_CLASS(oc);
+
+klass->kvm_init = pef_kvm_init;
+klass->kvm_reset = pef_kvm_reset;
 }
 
 static void pef_guest_init(Object *obj)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 36ada4d0baf..533ea0f9142 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -75,6 +75,7 @@
 #include "hw/virtio/vhost-scsi-common.h"
 
 #include "exec/ram_addr.h"
+#include "exec/confidential-guest-support.h"
 #include "hw/usb.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
@@ -87,7 +88,6 @@
 #include "hw/ppc/spapr_tpm_proxy.h"
 #include "hw/ppc/spapr_nvdimm.h"
 #include "hw/ppc/spapr_numa.h"
-#include "hw/ppc/pef.h"
 
 #include "monitor/monitor.h"
 
@@ -1715,7 +1715,9 @@ static void spapr_machine_reset(MachineState *machine, 
ShutdownCause reason)
 qemu_guest_getrandom_nofail(spapr->fdt_rng_seed, 32);
 }
 
-pef_kvm_reset(machine->cgs, &error_fatal);
+if (machine->cgs) {
+confidential_guest_kvm_reset(machine->cgs, &error_fatal);
+}
 spapr_caps_apply(spapr);
 spapr_nested_reset(spapr);
 
@@ -2841,7 +2843,9 @@ static void spapr_machine_init(MachineState *machine)
 /*
  * if Secure VM (PEF) support is configured, then initialize it
  */
-pef_kvm_init(machine->cgs, &error_fatal);
+if (machine->cgs) {
+confidential_guest_kvm_init(machine->cgs, &error_fatal);
+}
 
 msi_nonbroken = true;
 
-- 
2.44.0

[PULL 08/63] hw: Include minimal source set in user emulation build

[Paolo Bonzini]

From: Philippe Mathieu-Daudé 

Only the files in hwcore_ss[] are required to link a user emulation
binary.

Have meson process the hw/ sub-directories if system emulation is
selected, otherwise directly process hw/core/ to get hwcore_ss[], which
is the only set required by user emulation.

This removes about 10% from the time needed to run
"../configure --disable-system --disable-tools --disable-guest-agent".

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-ID: <20240404194757.9343-8-phi...@linaro.org>
Signed-off-by: Paolo Bonzini 
Message-ID: <20240408155330.522792-9-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 meson.build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 8c1271b8846..84e59dcbb49 100644
--- a/meson.build
+++ b/meson.build
@@ -3451,8 +3451,12 @@ subdir('qom')
 subdir('authz')
 subdir('crypto')
 subdir('ui')
-subdir('hw')
 subdir('gdbstub')
+if have_system
+  subdir('hw')
+else
+  subdir('hw/core')
+endif
 
 if enable_modules
   libmodulecommon = static_library('module-common', files('module-common.c') + 
genh, pic: true, c_args: '-DBUILD_DSO')
-- 
2.44.0

[PULL 51/63] kvm/memory: Make memory type private by default if it has guest memfd backend

[Paolo Bonzini]

From: Xiaoyao Li 

KVM side leaves the memory to shared by default, which may incur the
overhead of paging conversion on the first visit of each page. Because
the expectation is that page is likely to private for the VMs that
require private memory (has guest memfd).

Explicitly set the memory to private when memory region has valid
guest memfd backend.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Michael Roth 
Message-ID: <20240320083945.991426-16-michael.r...@amd.com>
Signed-off-by: Paolo Bonzini 
---
 accel/kvm/kvm-all.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 0386d4901fa..f49b2b95b54 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1431,6 +1431,16 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
 strerror(-err));
 abort();
 }
+
+if (memory_region_has_guest_memfd(mr)) {
+err = kvm_set_memory_attributes_private(start_addr, slot_size);
+if (err) {
+error_report("%s: failed to set memory attribute private: %s",
+ __func__, strerror(-err));
+exit(1);
+}
+}
+
 start_addr += slot_size;
 ram_start_offset += slot_size;
 ram += slot_size;
-- 
2.44.0

[PULL 53/63] RAMBlock: make guest_memfd require uncoordinated discard

[Paolo Bonzini]

Some subsystems like VFIO might disable ram block discard, but guest_memfd
uses discard operations to implement conversions between private and
shared memory.  Because of this, sequences like the following can result
in stale IOMMU mappings:

1. allocate shared page
2. convert page shared->private
3. discard shared page
4. convert page private->shared
5. allocate shared page
6. issue DMA operations against that shared page

This is not a use-after-free, because after step 3 VFIO is still pinning
the page.  However, DMA operations in step 6 will hit the old mapping
that was allocated in step 1.

Address this by taking ram_block_discard_is_enabled() into account when
deciding whether or not to discard pages.

Since kvm_convert_memory()/guest_memfd doesn't implement a
RamDiscardManager handler to convey and replay discard operations,
this is a case of uncoordinated discard, which is blocked/released
by ram_block_discard_require().  Interestingly, this function had
no use so far.

Alternative approaches would be to block discard of shared pages, but
this would cause guests to consume twice the memory if they use VFIO;
or to implement a RamDiscardManager and only block uncoordinated
discard, i.e. use ram_block_coordinated_discard_require().

[Commit message mostly by Michael Roth ]

Signed-off-by: Paolo Bonzini 
---
 system/physmem.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/system/physmem.c b/system/physmem.c
index f5dfa20e57e..5ebcf5be116 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -1846,6 +1846,13 @@ static void ram_block_add(RAMBlock *new_block, Error 
**errp)
 assert(kvm_enabled());
 assert(new_block->guest_memfd < 0);
 
+if (ram_block_discard_require(true) < 0) {
+error_setg_errno(errp, errno,
+ "cannot set up private guest memory: discard 
currently blocked");
+error_append_hint(errp, "Are you using assigned devices?\n");
+goto out_free;
+}
+
 new_block->guest_memfd = kvm_create_guest_memfd(new_block->max_length,
 0, errp);
 if (new_block->guest_memfd < 0) {
@@ -2109,6 +2116,7 @@ static void reclaim_ramblock(RAMBlock *block)
 
 if (block->guest_memfd >= 0) {
 close(block->guest_memfd);
+ram_block_discard_require(false);
 }
 
 g_free(block);
-- 
2.44.0

[PULL 48/63] kvm: Introduce support for memory_attributes

[Paolo Bonzini]

From: Xiaoyao Li 

Introduce the helper functions to set the attributes of a range of
memory to private or shared.

This is necessary to notify KVM the private/shared attribute of each gpa
range. KVM needs the information to decide the GPA needs to be mapped at
hva-based shared memory or guest_memfd based private memory.

Signed-off-by: Xiaoyao Li 
Message-ID: <20240320083945.991426-11-michael.r...@amd.com>
Signed-off-by: Paolo Bonzini 
---
 include/sysemu/kvm.h |  4 
 accel/kvm/kvm-all.c  | 32 
 2 files changed, 36 insertions(+)

diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index bd247f3a239..594ae9b4605 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -536,4 +536,8 @@ void kvm_mark_guest_state_protected(void);
  * reported for the VM.
  */
 bool kvm_hwpoisoned_mem(void);
+
+int kvm_set_memory_attributes_private(hwaddr start, uint64_t size);
+int kvm_set_memory_attributes_shared(hwaddr start, uint64_t size);
+
 #endif
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index ed50c80b1e4..db0b1a16edd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -91,6 +91,7 @@ bool kvm_msi_use_devid;
 static bool kvm_has_guest_debug;
 static int kvm_sstep_flags;
 static bool kvm_immediate_exit;
+static uint64_t kvm_supported_memory_attributes;
 static hwaddr kvm_max_slot_size = ~0;
 
 static const KVMCapabilityInfo kvm_required_capabilites[] = {
@@ -1266,6 +1267,36 @@ void kvm_set_max_memslot_size(hwaddr max_slot_size)
 kvm_max_slot_size = max_slot_size;
 }
 
+static int kvm_set_memory_attributes(hwaddr start, uint64_t size, uint64_t 
attr)
+{
+struct kvm_memory_attributes attrs;
+int r;
+
+assert((attr & kvm_supported_memory_attributes) == attr);
+attrs.attributes = attr;
+attrs.address = start;
+attrs.size = size;
+attrs.flags = 0;
+
+r = kvm_vm_ioctl(kvm_state, KVM_SET_MEMORY_ATTRIBUTES, &attrs);
+if (r) {
+error_report("failed to set memory (0x%" HWADDR_PRIx "+0x%" PRIx64 ") "
+ "with attr 0x%" PRIx64 " error '%s'",
+ start, size, attr, strerror(errno));
+}
+return r;
+}
+
+int kvm_set_memory_attributes_private(hwaddr start, uint64_t size)
+{
+return kvm_set_memory_attributes(start, size, 
KVM_MEMORY_ATTRIBUTE_PRIVATE);
+}
+
+int kvm_set_memory_attributes_shared(hwaddr start, uint64_t size)
+{
+return kvm_set_memory_attributes(start, size, 0);
+}
+
 /* Called with KVMMemoryListener.slots_lock held */
 static void kvm_set_phys_mem(KVMMemoryListener *kml,
  MemoryRegionSection *section, bool add)
@@ -2387,6 +2418,7 @@ static int kvm_init(MachineState *ms)
 goto err;
 }
 
+kvm_supported_memory_attributes = kvm_check_extension(s, 
KVM_CAP_MEMORY_ATTRIBUTES);
 kvm_immediate_exit = kvm_check_extension(s, KVM_CAP_IMMEDIATE_EXIT);
 s->nr_slots = kvm_check_extension(s, KVM_CAP_NR_MEMSLOTS);
 
-- 
2.44.0

[PULL 12/63] semihosting: move stubs out of stubs/

[Paolo Bonzini]

Since the semihosting stubs are needed exactly when the Kconfig symbols
are not needed, move them to semihosting/ and conditionalize them
on CONFIG_SEMIHOSTING and/or CONFIG_SYSTEM_ONLY.

Signed-off-by: Paolo Bonzini 
Message-ID: <20240408155330.522792-13-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 stubs/semihost-all.c => semihosting/stubs-all.c | 0
 stubs/semihost.c => semihosting/stubs-system.c  | 0
 semihosting/meson.build | 3 +++
 stubs/meson.build   | 2 --
 4 files changed, 3 insertions(+), 2 deletions(-)
 rename stubs/semihost-all.c => semihosting/stubs-all.c (100%)
 rename stubs/semihost.c => semihosting/stubs-system.c (100%)

diff --git a/stubs/semihost-all.c b/semihosting/stubs-all.c
similarity index 100%
rename from stubs/semihost-all.c
rename to semihosting/stubs-all.c
diff --git a/stubs/semihost.c b/semihosting/stubs-system.c
similarity index 100%
rename from stubs/semihost.c
rename to semihosting/stubs-system.c
diff --git a/semihosting/meson.build b/semihosting/meson.build
index b07cbd980f2..34933e5a195 100644
--- a/semihosting/meson.build
+++ b/semihosting/meson.build
@@ -9,5 +9,8 @@ specific_ss.add(when: ['CONFIG_SEMIHOSTING', 
'CONFIG_SYSTEM_ONLY'], if_true: fil
   'uaccess.c',
 ))
 
+common_ss.add(when: ['CONFIG_SEMIHOSTING', 'CONFIG_SYSTEM_ONLY'], if_false: 
files('stubs-all.c'))
+system_ss.add(when: ['CONFIG_SEMIHOSTING'], if_false: files('stubs-system.c'))
+
 specific_ss.add(when: ['CONFIG_ARM_COMPATIBLE_SEMIHOSTING'],
if_true: files('arm-compat-semi.c'))
diff --git a/stubs/meson.build b/stubs/meson.build
index 60e32d363fa..84ecaa4daa1 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -55,9 +55,7 @@ if have_block or have_ga
 endif
 if have_system
   stub_ss.add(files('fw_cfg.c'))
-  stub_ss.add(files('semihost.c'))
   stub_ss.add(files('xen-hw-stub.c'))
 else
   stub_ss.add(files('qdev.c'))
 endif
-stub_ss.add(files('semihost-all.c'))
-- 
2.44.0

[PULL 38/63] linux-headers: update to current kvm/next

[Paolo Bonzini]

Signed-off-by: Paolo Bonzini 
---
 include/standard-headers/asm-x86/bootparam.h  |  17 +-
 include/standard-headers/asm-x86/kvm_para.h   |   3 +-
 include/standard-headers/asm-x86/setup_data.h |  83 +++
 include/standard-headers/linux/ethtool.h  |  48 ++
 include/standard-headers/linux/fuse.h |  39 +-
 .../linux/input-event-codes.h |   1 +
 include/standard-headers/linux/virtio_gpu.h   |   2 +
 include/standard-headers/linux/virtio_pci.h   |  10 +-
 include/standard-headers/linux/virtio_snd.h   | 154 
 linux-headers/asm-arm64/kvm.h |  15 +-
 linux-headers/asm-arm64/sve_context.h |  11 +
 linux-headers/asm-generic/bitsperlong.h   |   4 +
 linux-headers/asm-loongarch/kvm.h |   2 -
 linux-headers/asm-mips/kvm.h  |   2 -
 linux-headers/asm-powerpc/kvm.h   |  45 +-
 linux-headers/asm-riscv/kvm.h |   3 +-
 linux-headers/asm-s390/kvm.h  | 315 +++-
 linux-headers/asm-x86/kvm.h   | 328 -
 linux-headers/linux/bits.h|  15 +
 linux-headers/linux/kvm.h | 689 +-
 linux-headers/linux/psp-sev.h |  59 ++
 linux-headers/linux/vhost.h   |   7 +
 hw/i386/x86.c |   8 -
 23 files changed, 1120 insertions(+), 740 deletions(-)
 create mode 100644 include/standard-headers/asm-x86/setup_data.h
 create mode 100644 linux-headers/linux/bits.h

diff --git a/include/standard-headers/asm-x86/bootparam.h 
b/include/standard-headers/asm-x86/bootparam.h
index 0b06d2bff1b..b582a105c08 100644
--- a/include/standard-headers/asm-x86/bootparam.h
+++ b/include/standard-headers/asm-x86/bootparam.h
@@ -2,21 +2,7 @@
 #ifndef _ASM_X86_BOOTPARAM_H
 #define _ASM_X86_BOOTPARAM_H
 
-/* setup_data/setup_indirect types */
-#define SETUP_NONE 0
-#define SETUP_E820_EXT 1
-#define SETUP_DTB  2
-#define SETUP_PCI  3
-#define SETUP_EFI  4
-#define SETUP_APPLE_PROPERTIES 5
-#define SETUP_JAILHOUSE6
-#define SETUP_CC_BLOB  7
-#define SETUP_IMA  8
-#define SETUP_RNG_SEED 9
-#define SETUP_ENUM_MAX SETUP_RNG_SEED
-
-#define SETUP_INDIRECT (1<<31)
-#define SETUP_TYPE_MAX (SETUP_ENUM_MAX | SETUP_INDIRECT)
+#include "standard-headers/asm-x86/setup_data.h"
 
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK   0x07FF
@@ -38,6 +24,7 @@
 #define XLF_EFI_KEXEC  (1<<4)
 #define XLF_5LEVEL (1<<5)
 #define XLF_5LEVEL_ENABLED (1<<6)
+#define XLF_MEM_ENCRYPTION (1<<7)
 
 
 #endif /* _ASM_X86_BOOTPARAM_H */
diff --git a/include/standard-headers/asm-x86/kvm_para.h 
b/include/standard-headers/asm-x86/kvm_para.h
index f0235e58a1d..9a011d20f01 100644
--- a/include/standard-headers/asm-x86/kvm_para.h
+++ b/include/standard-headers/asm-x86/kvm_para.h
@@ -92,7 +92,7 @@ struct kvm_clock_pairing {
 #define KVM_ASYNC_PF_DELIVERY_AS_INT   (1 << 3)
 
 /* MSR_KVM_ASYNC_PF_INT */
-#define KVM_ASYNC_PF_VEC_MASK  GENMASK(7, 0)
+#define KVM_ASYNC_PF_VEC_MASK  __GENMASK(7, 0)
 
 /* MSR_KVM_MIGRATION_CONTROL */
 #define KVM_MIGRATION_READY(1 << 0)
@@ -142,7 +142,6 @@ struct kvm_vcpu_pv_apf_data {
uint32_t token;
 
uint8_t pad[56];
-   uint32_t enabled;
 };
 
 #define KVM_PV_EOI_BIT 0
diff --git a/include/standard-headers/asm-x86/setup_data.h 
b/include/standard-headers/asm-x86/setup_data.h
new file mode 100644
index 000..09355f54c55
--- /dev/null
+++ b/include/standard-headers/asm-x86/setup_data.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _ASM_X86_SETUP_DATA_H
+#define _ASM_X86_SETUP_DATA_H
+
+/* setup_data/setup_indirect types */
+#define SETUP_NONE 0
+#define SETUP_E820_EXT 1
+#define SETUP_DTB  2
+#define SETUP_PCI  3
+#define SETUP_EFI  4
+#define SETUP_APPLE_PROPERTIES 5
+#define SETUP_JAILHOUSE6
+#define SETUP_CC_BLOB  7
+#define SETUP_IMA  8
+#define SETUP_RNG_SEED 9
+#define SETUP_ENUM_MAX SETUP_RNG_SEED
+
+#define SETUP_INDIRECT (1<<31)
+#define SETUP_TYPE_MAX (SETUP_ENUM_MAX | SETUP_INDIRECT)
+
+#ifndef __ASSEMBLY__
+
+#include "standard-headers/linux/types.h"
+
+/* extensible setup data list node */
+struct setup_data {
+   uint64_t next;
+   uint32_t type;
+   uint32_t len;
+   uint8_t data[];
+};
+
+/* extensible setup indirect data node */
+struct setup_indirect {
+   uint32_t type;
+   uint32_t reserved;  /* Reserved, must be set to zero. */
+