On Fri, Dec 13, 2024 at 04:18:36PM +0000, Jonathan Cameron wrote: > On Thu, 12 Dec 2024 14:52:02 -0500 > Gregory Price <gou...@gourry.net> wrote: > > I don't think anyone is going to do 2MiB granularity on a real device > (or at least not for bulk capacity) so the necessary data may not be that > large. > Obviously the cost of updating it will be higher, but meh, that's not that > common an operation. > > > > > > and we can have > > > richer info. Having to chat to each qmp interface independently works > > > fine is > > > also a bit more complex than I think we would eventually want. > > > > > > > This is a small component in someone's fabric manager that translates their > > requests into QMP commands. Whatever we ultimately decide on, the > > complexity > > here is about the same. > > It's the qmp commands to a bunch of different qemu instances pretending to be > one > Multi Head device. > Sure we can insert a proxy to act as that one, but then we more or less > have an external process mediating that. >
I'm not against changing this, I just think it's going to increase complexity for little value. I personally like the idea of keeping it the way it is and slapping a small proxy on top that emulates the "out of band" interface to the device - but all it does behind the scenes is send out a QMP command (that already exists) to a guest that registered itself with the proxy. This separates the complexity of implementing FMAPI functionality and the complexity of how an individual instance of QEMU go about handling add/access/remove semantics for DCD events. The annoying thought experiment here is when someone wants their in-band host interface to have access to the FMAPI great now i've made myself grumpy > > > > > Having a solution in place though will make it much easier to move towards > > > an eventual upstreamable solution. This is a great place to start from! > > > > > > Jonathan > > > > > > > +/* > > > > + * We limit the number of heads to prevent the shared state > > > > + * region from becoming a major memory hog. We need 512MB of > > > > + * memory space to track 8-host ownership of 4GB of memory in > > > > + * blocks of 2MB. This can change if the block size is increased. > > > > > > I'm lost what makes up that size? > > > > > > > I think the math is wrong here, we may have calculated based on > > a larger capacity. I need to go back and look at how we came to 512MB. > 4TB maybe? > > Jonathan Yeah that's probably what it was. I think that's what I was basing it off of at the time. ~Gregory
