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

Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce elf_load_image



>>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
>> >>> On 09.12.11 at 14:13, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > Implement a new function, called elf_load_image, to perform the actually
>> > copy of the elf image and clearing the padding.
>> > The function is implemented as memcpy and memset when the library is
>> > built as part of the tools, but it is implemented as copy_to_user and
>> > clear_user when built as part of Xen, so that it can be safely called
>> > with an HVM style dom0.
>> 
>> I meant to ask this on the first round already, but apparently forgot:
>> What is it that prevents memcpy()/memset() from being used for a
>> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
>> to be visible in the hypervisor's virtual address space - how could a
>> fault happen here? And if you have to take precautions for a fault,
>> shouldn't the calling code check the respective return values?
> 
> HVM guest memory is not (necessarily) mapped in the hypervisor page
> tables, it needs to be mapped on demand. Also the source/target (delete
> as appropriate) is a guest virtual address so even if the RAM happened
> to be mapped it would (likely) not be in the same place so at a minimum
> we need to translate things.
> 
> This is what copy_{to,from}_user does for an HVM guest even on X86,
> where copy_to_user becomes copy_to_user_hvm as appropriate. 

But that's not true - the distinction of hvm vs pv is at the
copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
maybe the patch meant to use those interfaces (and then we'd need
a clear_guest() too, which should also have been obvious by the fact
that the prior patch only introduced clear_user(), but no hvm variant
of it)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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