----- 6 lip 2020 o 11:47, Andrew Cooper [email protected] napisał(a):
> On 06/07/2020 09:33, Jan Beulich wrote: >> On 05.07.2020 20:58, Michał Leszczyński wrote: >>> ----- 5 lip 2020 o 20:55, Michał Leszczyński [email protected] >>> napisał(a): >>>> --- /dev/null >>>> +++ b/tools/proctrace/proctrace.c >>>> +#include <stdlib.h> >>>> +#include <stdio.h> >>>> +#include <sys/mman.h> >>>> +#include <signal.h> >>>> + >>>> +#include <xenctrl.h> >>>> +#include <xen/xen.h> >>>> +#include <xenforeignmemory.h> >>>> + >>>> +#define BUF_SIZE (16384 * XC_PAGE_SIZE) >>> I would like to discuss here, how we should retrieve the trace buffer size >>> in runtime? Should there be a hypercall for it, or some extension to >>> acquire_resource logic? >> Personally I'd prefer the latter, but the question is whether one can >> be made in a backwards compatible way. > > I already covered this in v4. > > ~Andrew Ok, sorry, I see: > The guest_handle_is_null(xmar.frame_list) path > in Xen is supposed to report the size of the resource, not the size of > Xen's local buffer, so userspace can ask "how large is this resource". > > I'll try and find some time to fix this and arrange for backports, but > the current behaviour is nonsense, and problematic for new users. So to make it clear: should I modify the acquire_resource logic in such way that NULL guest handle would report the actual size of the resource? If I got it right, here: https://lists.xen.org/archives/html/xen-devel/2020-07/msg00159.html it was suggested that it should report the constant value of UINT_MAX >> MEMOP_EXTENT_SHIFT and as far as I understood, the expectation is that it would report how many frames might be requested at once, not what is the size of the resource we're asking for. Best regards, Michał Leszczyński CERT Polska
