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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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. 

Ian.



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