[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 01/19] common/symbols: Export hypervisor symbols to privileged guest

>>> On 16.05.14 at 16:58, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 05/16/2014 04:05 AM, Jan Beulich wrote:
>> Considering that xensyms_read() is there only to implement this sub-
>> hypercall, I wonder whether you wouldn't be better of passing it the
>> handle, and have it do the copying. It's holding a lock itself, so the
>> static buffer could be placed there, along with the other statics it
>> already uses (which btw should go into the only function that make
>> use of them).
> I didn't want to expose xensyms_read() to any handles to keep it a 
> purely "internal" (for the lack of a better term) routine.
> But if 'name' is to become static I don't want to introduce another lock 
> (or move existing one up from xensyms_read()) so I guess I would have to 
> pass the handle.

No, even in the caller you're already protected by a lock.

>> And finally (I think I commented on this too earlier on) you still don't
>> have the caller pass in the size of the buffer it wants the symbol
>> copied to, and instead bake into the hypercall interface an arbitrary
>> (derived from current Xen internals) fixed name length. That's non-
>> extensible.
> So do you suggest passing in (and out) buffer size?

Since the output is nul-terminated, I don't see a strict need for passing
it out, but I clearly want it to be passed in.

>>> --- a/xen/arch/x86/x86_64/platform_hypercall.c
>>> +++ b/xen/arch/x86/x86_64/platform_hypercall.c
>>> @@ -32,6 +32,8 @@ CHECK_pf_pcpu_version;
>>>   CHECK_pf_enter_acpi_sleep;
>>>   #undef xen_pf_enter_acpi_sleep
>>> +#define xenpf_symdata   compat_pf_symdata
>> Did you check that you really need this? There's no explicit instance of
>> the structure, so I would think it's not needed.
> Isn't this required for auto-building compat interfaces?

That depends, and it seems to me that it's not needed here.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.