Am 15.03.2017 um 16:09 hat Paolo Bonzini geschrieben: > >>>> There should be a policy on which BB sets AioContext on the BDS (e.g. > >>>> only the device does it), but apart from that, it should not be an issue. > >>> > >>> We don't know which BBs are going to be attached. We don't necessarily > >>> have a device at all, or we could have two of them. > >> > >> Wow, can we really have two? :-O > > > > What would prevent you from doing this? The whole blockdev work was > > about making the block layer more flexible, so now we have this > > flexibility of attaching more or less anything to anything (unless op > > blockers prevent it, which is why they are important for actually > > supporting blockdev). > > Yeah, the actual question was more "will the blockers allow two" devices > behind the same BDS. But I suppose there's no reason to prevent that > (emulating multipath, for example).
For read-only devices, there's no reason anyway. For writable ones, you have to set the share-rw=on qdev property, but then it's allowed. > >>> Though maybe we should try to keep a BDS and its children in the same > >>> AioContext anyway if that's possible? Will it make a difference? > >> > >> Everything can make sense---but yes, keeping the whole hierarchy in the > >> same AioContext makes sense more often. > > > > So I take this to mean that it does make a difference. :-) > > > > If we want to keep users and their child nodes in the same AioContext by > > default, we'll probably still need to implement all of the callbacks > > that we would need for proper AioContext management today. > > Or just assume that in the common case people won't specify iothread on > -blockdev, only on -device. Right, but then attaching a new device could mean that the BDS moves to a different AioContext even though the other users are still on the old one. Not sure if this is bad, but it might be unexpected. Kevin