Re: [Xen-devel] [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole

[Hanweidong <hanweidong@xxxxxxxxxx>]

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> Sent: 2013å6æ18æ 20:44
> To: Hanweidong
> Cc: xen-devel@xxxxxxxxxxxxx; Ian Campbell; Ian Jackson; Stefano
> Stabellini
> Subject: Re: [PATCH] libxl,hvmloader: Don't relocate memory for MMIO
> hole
> 
> On 06/18/2013 01:18 PM, Hanweidong wrote:
> >> -----Original Message-----
> >> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> >> Sent: 2013å6æ18æ 0:49
> >> To: George Dunlap
> >> Cc: xen-devel@xxxxxxxxxxxxx; Ian Campbell; Ian Jackson; Stefano
> >> Stabellini; Hanweidong
> >> Subject: Re: [PATCH] libxl,hvmloader: Don't relocate memory for MMIO
> >> hole
> >>
> >> On 17/06/13 17:43, George Dunlap wrote:
> >>> At the moment, qemu-xen can't handle memory being relocated by
> >>> hvmloader.  This may happen if a device with a large enough memory
> >>> region is passed through to the guest.  At the moment, if this
> >>> happens, then at some point in the future qemu will crash and the
> >>> domain will hang.  (qemu-traditional is fine.)
> >>>
> >>> It's too late in the release to do a proper fix, so we try to do
> >>> damage control.
> >>>
> >>> hvmloader already has mechanisms to relocate memory to 64-bit space
> >>> if it can't make a big enough MMIO hole.  By default this is 2GiB;
> if
> >>> we just refuse to make the hole bigger if it will overlap with
> guest
> >>> memory, then this codepath will be taken by default.
> >>>
> >>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> >>> CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
> >>> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> >>> CC: Hanweidong <hanweidong@xxxxxxxxxx>
> >>
> >> Unfortunatley, I don't have an easy way to test this, as all of the
> >> devices on my system are far smaller than 256MiB.
> >>
> >> Weidong, could you give this patch a try and see if it works for you?
> >>
> >
> > Georgeï
> >
> > I don't have a system in hand to test it today. I try to have a test
> tomorrow. In my experience, when it's prevented to relocate memory for
> MMIO hole by your patch, windows guest will crash (blue screen) and
> linux guest will hang with a blank display.
> 
> Actually, did you have a way of testing this without actually having a
> real device to test it with?  That would help me sort things out much
> more quickly.
> 

I think you can try it with ivshmem device emulated in QEMU. Ivshmem device can 
be configured with large mmio. Ivshmem code only be compiled for kvm by 
default, you can change the makefile to compile it for xen also. And then 
hardcode to create a ivshmem device for a VM in vl.c. At last, you also need to 
run the ivshmem-server in dom0. 

weidong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel