> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: 26 May 2026 09:37
> To: Nicolin Chen <[email protected]>
> Cc: Shameer Kolothum Thodi <[email protected]>; qemu-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Nathan Chen <[email protected]>;
> Matt Ochs <[email protected]>; Jiandi An <[email protected]>; Jason
> Gunthorpe <[email protected]>; [email protected]; Krishnakant Jaju
> <[email protected]>; [email protected]
> Subject: Re: [PATCH v5 19/32] hw/arm/tegra241-cmdqv: Allocate HW
> VCMDQs once configured
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Nicolin,
> 
> On 5/21/26 11:54 PM, Nicolin Chen wrote:
> > On Thu, May 21, 2026 at 03:27:17PM +0200, Eric Auger wrote:
> >> On 5/21/26 2:26 PM, Shameer Kolothum Thodi wrote:
> >>>>> +    /* Ignore any invalid address. This may come as part of reset etc. 
> >>>>> */
> >>>>> +    if (!address_space_range_is_ram(&address_space_memory, addr,
> size)) {
> >>>> why do you need to test the whole range and not only the start addressa
> >>> That was to make it more defensive based on v4 discussion here:
> >>> https://lore.kernel.org/qemu-devel/aft%[email protected]/
> >>>
> >>> Please let me know if there is a better way.
> >> Well it is unclear to me. You want to make sure the GPA was fully set
> >> through the H and L regs. To me that's enough. As far as I understand
> >> Nicolin's reply, the kernel checks the rest. But please sync with Jason
> >> or Nicolin
> > Yes. Kernel checks if the range is in the stage-2 page table, i.e.,
> > mapped GPAs. One caveat: mapped GPA doesn't guarantee it's is_ram.
> >
> > So, what if the GPA is in the IO space (PCI BAR) or reserved space
> > (firmware)?

Looking at our helper address_space_range_is_ram(), it isn't foolproof
for the above cases. For the PCI BAR case we could add:

    if (!memory_region_is_ram(mr) || memory_region_is_ram_device(mr)) {
        return false;
    }

But I'm not sure how to tackle the reserved spaces. For firmware ROM
we could add a memory_region_is_rom() check, but the others will
still look like normal RAM, so they're hard to detect at this layer.

> >
> > AFAIK, kernel doesn't have a way to know. So, it's VMM's job to do
> > so.
> would it jeopardize the host integrity or would it just break the
> misbehaving guest. If the latest I am not sure this is critical to
> check. We are not checking either with regular SMMU cmd queues

I think it would just be the guest shooting itself in the foot. Can't think
of a host security/integrity issue here. So we could drop the check if
that's preferred.

Thanks,
Shameer

Reply via email to