Re: [PATCH v3] hw/arm/virt-acpi-build: Fix id_count in build_iort_id_mapping

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Jun 18, 2024 at 05:34:21PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jun 18, 2024 at 02:19:25PM -0700, Nicolin Chen wrote:
> > On Tue, Jun 18, 2024 at 05:14:32PM -0400, Michael S. Tsirkin wrote:
> > > > @@ -306,8 +314,8 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> > > >          }
> > > >
> > > >          /* Append the last RC -> ITS ID mapping */
> > > > -        if (next_range.input_base < 0xFFFF) {
> > > > -            next_range.id_count = 0xFFFF - next_range.input_base;
> > > > +        if (next_range.input_base < 0x10000) {
> > > > +            next_range.id_count = 0x10000 - next_range.input_base;
> > > >              g_array_append_val(its_idmaps, next_range);
> > > >          }
> > >
> > > A change of logic here - I think the new one is right and old
> > > one was wrong, actually. Right?
> >
> > Sorry, I don't quite follow that question...
> >
> > Doesn't a patch correct an old wrong one to a new right one?
> >
> > Thanks
> > Nicolin
> 
> 
> So if base is 0xFFFF what should happen? I think previously we
> skipped an entry and that is wrong. So that's another latent
> bug this patch fixes then?
> Worth documenting in the commit log too.

I had noticed that -- yes, ideally it should have been "<= 0xFFFF".
Yet, practically input_base can never be 0xFFFF as it's calculated:

hw/arm/virt-acpi-build.c:245:                .input_base = min_bus << 8,
hw/arm/virt-acpi-build.c:305:            next_range.input_base = idmap->input_base + idmap->id_count;

The first one always sets input_base to 0xXX00 (min_bus = 0xXX).
The second one, as we know for id_count, must be 0xZZ00 too since
input_base from the first place must be 0xXX00 and 0xYY00
hw/arm/virt-acpi-build.c:301:                next_range.id_count = idmap->input_base - next_range.input_base;

So, it's a case that could never be triggered? Probably not worth
highlighting IMOH...

Thanks
Nicolin