On Mon, 2020-05-11 at 13:11 +0200, Paolo Bonzini wrote:
> On 11/05/20 13:00, Maxim Levitsky wrote:
> > On second thought, I think both cases matter, after I examined the device
> > removal case.
> > In device removal case, the device is first un-realized and then removed
> > from the bus,
> > so
On 11/05/20 13:00, Maxim Levitsky wrote:
> On second thought, I think both cases matter, after I examined the device
> removal case.
> In device removal case, the device is first un-realized and then removed from
> the bus,
> so just like in device hotplug case, the scsi_device_find can give you
On Mon, 2020-05-04 at 13:22 +0200, Paolo Bonzini wrote:
> On 04/05/20 12:45, Stefan Hajnoczi wrote:
> > > @@ -983,7 +983,7 @@ static void device_set_realized(Object *obj, bool
> > > value, Error **errp)
> > > }
> > >
> > > assert(local_err == NULL);
> > > -dev->realized = value;
>
On Mon, 2020-05-04 at 13:22 +0200, Paolo Bonzini wrote:
> On 04/05/20 12:45, Stefan Hajnoczi wrote:
> > > @@ -983,7 +983,7 @@ static void device_set_realized(Object *obj, bool
> > > value, Error **errp)
> > > }
> > >
> > > assert(local_err == NULL);
> > > -dev->realized = value;
>
On 04/05/20 12:45, Stefan Hajnoczi wrote:
>> @@ -983,7 +983,7 @@ static void device_set_realized(Object *obj, bool value,
>> Error **errp)
>> }
>>
>> assert(local_err == NULL);
>> -dev->realized = value;
>> +atomic_set(&dev->realized, value);
> A memory barrier is probably need
On Thu, Apr 16, 2020 at 11:36:23PM +0300, Maxim Levitsky wrote:
> Some code might race with placement of new devices on a bus.
> We currently first place a (unrealized) device on the bus
> and then realize it.
>
> As a workaround, users that scan the child device list, can
> check the realized pro
Some code might race with placement of new devices on a bus.
We currently first place a (unrealized) device on the bus
and then realize it.
As a workaround, users that scan the child device list, can
check the realized property to see if it is safe to access such a device.
Use an atomic write here
