On Mon, May 13, 2019 at 01:38:57PM +0100, Andrew Jones wrote: > On Mon, May 13, 2019 at 12:15:56PM +0100, Dave Martin wrote: > > On Mon, May 13, 2019 at 10:32:46AM +0100, Andrea Bolognani wrote: > > > On Sun, 2019-05-12 at 10:36 +0200, Andrew Jones wrote:
[...] > > > > The QMP query returns a list of valid vq lists. For example, if > > > > a guest can use vqs 1, 2, 3, and 4, then the following list will > > > > be returned > > > > > > > > [ [ 1 ], [ 1, 2 ], [ 1, 2, 3 ], [ 1, 2, 3, 4 ] ] > > > > > > > > Another example might be 1, 2, 4, as the architecture states 3 > > > > is optional. In that case the list would be > > > > > > > > [ [ 1 ], [ 1, 2 ], [ 1, 2, 4 ] ] > > > > > > I think the proposed QMP command is problematic, because it reports > > > the valid vector lengths for either KVM or TCG based on which > > > accelerator is currently enabled: it should report all information > > > at all times instead, similarly to how query-gic-capabilities does > > > it. > > > > I wonder if this is premature flexibility? > > > > The size of these lists is going to get cumbersome if the architecture > > is ever extended. Even today, we might need over 100 items in this > > (nested) list. If this is to be presented to the user this will be > > far from friendly, it could get much worse if the architecutre changes > > in future to allow larger vectors or more flexible virtualisation. > > > > Could we just have a list of supported vector lengths and a possibly > > empty list of additional capabilities that describe what kinds of > > flexibility are allowed? > > > > So, for example, we might support vector lengths of 1, 2, 4 and 8 > > quadwords, with the the ability to clamp the max vector length the > > guest sees: the kernel ABI guarantees that you can do this, even > > if you can't disable/enable each individual vector length independently. > > > > So, [ 1, 2, 4, 8 ] seems sufficient to describe this in a forwards > > compatible way. > > > > Some day, we might report { "independent", [ 1, 2, 4, 8, 16, 32, ... ] } > > > > I'm guessing about the data representation here. > > > > I think that could work, and something along those lines even crossed my > mind. Let's see what libvirt folk say. I'm not overly concerned about > user friendless here though, as users aren't running QMP commands and > parsing json by hand too much. One concern I have is that if the architecture ever supports masking out vector lengths individually, the size of this description becomes something like O(2^n) in the maximum vector length, instead of O(n^2). That could be very painful to deal with... Cheers ---Dave