qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 01/13] intel_iommu: allocate new key when cr


From: Liu, Yi L
Subject: Re: [Qemu-devel] [RFC PATCH 01/13] intel_iommu: allocate new key when creating new address space
Date: Wed, 14 Dec 2016 03:24:01 +0000

> -----Original Message-----
> From: Qemu-devel [mailto:address@hidden On
> Behalf Of Peter Xu
> Sent: Wednesday, December 14, 2016 11:06 AM
> To: Liu, Yi L <address@hidden>; Jason Wang <address@hidden>
> Cc: Lan, Tianyu <address@hidden>; Tian, Kevin <address@hidden>;
> address@hidden; address@hidden; address@hidden; qemu-
> address@hidden; address@hidden; Liu, Yi <address@hidden>
> Subject: Re: [Qemu-devel] [RFC PATCH 01/13] intel_iommu: allocate new key when
> creating new address space
> 
> On Mon, Dec 12, 2016 at 04:16:50PM +0800, Liu, Yi L wrote:
> > On Tue, Dec 06, 2016 at 06:36:16PM +0800, Peter Xu wrote:
> > > From: Jason Wang <address@hidden>
> > >
> > > We use the pointer to stack for key for new address space, this will
> > > break hash table searching, fixing by g_malloc() a new key instead.
> > >
> > > Cc: Michael S. Tsirkin <address@hidden>
> > > Cc: Paolo Bonzini <address@hidden>
> > > Cc: Richard Henderson <address@hidden>
> > > Cc: Eduardo Habkost <address@hidden>
> > > Acked-by: Peter Xu <address@hidden>
> > > Signed-off-by: Jason Wang <address@hidden>
> > > Signed-off-by: Peter Xu <address@hidden>
> > > ---
> > >  hw/i386/intel_iommu.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 708770e..92e4064 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -2426,12 +2426,13 @@ VTDAddressSpace
> *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn)
> > >      VTDAddressSpace *vtd_dev_as;
> > >
> > >      if (!vtd_bus) {
> > > +        uintptr_t *new_key = g_malloc(sizeof(*new_key));
> > > +        *new_key = (uintptr_t)bus;
> > >          /* No corresponding free() */
> > >          vtd_bus = g_malloc0(sizeof(VTDBus) + sizeof(VTDAddressSpace *) * 
> > > \
> > >                              X86_IOMMU_PCI_DEVFN_MAX);
> > >          vtd_bus->bus = bus;
> > > -        key = (uintptr_t)bus;
> > > -        g_hash_table_insert(s->vtd_as_by_busptr, &key, vtd_bus);
> > > +        g_hash_table_insert(s->vtd_as_by_busptr, new_key, vtd_bus);
> > Hi Peter,
> > Your fix seems to answer an issue I encountered back in Oct. The symptom 
> > is: use
> the same bus value to
> > searcha previous inserted entry in s->vtd_as_by_busptr, the result is not 
> > found.
> >
> > really grt fix. could explain it a bit on why this change would fix the 
> > issue?
> 
> The old code is doing g_hash_table_insert() with "&key" as the hash
> key. However variable "key" is allocated on stack, so it's value might
> change after we return from vtd_find_add_as() (stack variables can
> only be used inside its functional scope). The patch switched to use
> g_malloc0(), that'll use heap memory rather than stack, which is safe.
> 
> (Forwarding this thankfulness to Jason who is the real author of this
>  fix :-)

Thanks for the explanation, Peter. I see. Then it is sure this really fix what
I encountered in Oct. Really a wonderful fix Jason~ 

> 
> Thanks,
> 
> -- peterx


reply via email to

[Prev in Thread] Current Thread [Next in Thread]