All of lore.kernel.org
 help / color / mirror / Atom feed
* __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers
@ 2009-08-20 15:30 Chuck Anderson
  2009-08-20 16:27 ` Keir Fraser
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Anderson @ 2009-08-20 15:30 UTC (permalink / raw)
  To: xen-devel

Do the guest virtual addresses passed by a hypervisor call on a 32-bit 
HVM with PV drivers guest to a 64-bit hypervisor need to lie below 
__HYPERVISOR_COMPAT_VIRT_START?  Both HVM and PVM domains have their 
hv_compat_vstart set to __HYPERVISOR_COMPAT_VIRT_START.  The 
hypervisor's compat layer is causing the balloon driver's 
HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation) 
hypervisor call to error out in xen/common/compat/memory.c 
compat_memory_op(), compat_handle_ok(), because the PVHVM guest's 
extent_start lies above __HYPERVISOR_COMPAT_VIRT_START.  The following 
patch appears to fix the problem but I want to make sure it is fixing 
the real bug:

diff -up xen-3.4.0/xen/arch/x86/domain.c.orig 
xen-3.4.0/xen/arch/x86/domain.c
--- xen-3.4.0/xen/arch/x86/domain.c.orig        2009-08-18 
13:09:30.000000000 -0700
+++ xen-3.4.0/xen/arch/x86/domain.c     2009-08-18 14:55:08.000000000 -0700
@@ -428,7 +428,12 @@ int arch_domain_create(struct domain *d,
 #endif /* __x86_64__ */

 #ifdef CONFIG_COMPAT
-    HYPERVISOR_COMPAT_VIRT_START(d) = __HYPERVISOR_COMPAT_VIRT_START;
+    if (is_hvm_domain(d)) {
+        HYPERVISOR_COMPAT_VIRT_START(d) = 
__HYPERVISOR_COMPAT_VIRT_START_NONE;
+    }
+    else {
+        HYPERVISOR_COMPAT_VIRT_START(d) = __HYPERVISOR_COMPAT_VIRT_START;
+    }
 #endif

    if ( (rc = paging_domain_init(d)) != 0 )
diff -up xen-3.4.0/xen/include/asm-x86/config.h.orig 
xen-3.4.0/xen/include/asm-x86/config.h
--- xen-3.4.0/xen/include/asm-x86/config.h.orig 2009-08-18 
13:22:16.000000000 -0700
+++ xen-3.4.0/xen/include/asm-x86/config.h      2009-08-18 
14:54:40.000000000 -0700
@@ -228,6 +228,7 @@ extern unsigned int video_mode, video_fl

 #ifndef __ASSEMBLY__

+#define __HYPERVISOR_COMPAT_VIRT_START_NONE 0xFFFFFFFF
 /* This is not a fixed value, just a lower limit. */
 #define __HYPERVISOR_COMPAT_VIRT_START 0xF5800000
 #define HYPERVISOR_COMPAT_VIRT_START(d) ((d)->arch.hv_compat_vstart)

Thanks,
Chuck

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers
  2009-08-20 15:30 __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers Chuck Anderson
@ 2009-08-20 16:27 ` Keir Fraser
  2009-08-20 17:37   ` Keir Fraser
  0 siblings, 1 reply; 4+ messages in thread
From: Keir Fraser @ 2009-08-20 16:27 UTC (permalink / raw)
  To: Chuck Anderson, xen-devel@lists.xensource.com

On 20/08/2009 16:30, "Chuck Anderson" <chuck.anderson@oracle.com> wrote:

> Do the guest virtual addresses passed by a hypervisor call on a 32-bit
> HVM with PV drivers guest to a 64-bit hypervisor need to lie below
> __HYPERVISOR_COMPAT_VIRT_START?  Both HVM and PVM domains have their
> hv_compat_vstart set to __HYPERVISOR_COMPAT_VIRT_START.  The
> hypervisor's compat layer is causing the balloon driver's
> HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation)
> hypervisor call to error out in xen/common/compat/memory.c
> compat_memory_op(), compat_handle_ok(), because the PVHVM guest's
> extent_start lies above __HYPERVISOR_COMPAT_VIRT_START.  The following
> patch appears to fix the problem but I want to make sure it is fixing
> the real bug:

Yeah, you pretty much have it figured. I may just clean up for style (I
think an extra macro for this is a bit pointless), but the patch is
fundamentally good.

 Thanks,
 Keir

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers
  2009-08-20 16:27 ` Keir Fraser
@ 2009-08-20 17:37   ` Keir Fraser
  2009-08-20 20:48     ` Chuck Anderson
  0 siblings, 1 reply; 4+ messages in thread
From: Keir Fraser @ 2009-08-20 17:37 UTC (permalink / raw)
  To: Chuck Anderson, xen-devel@lists.xensource.com

On 20/08/2009 17:27, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:

>> Do the guest virtual addresses passed by a hypervisor call on a 32-bit
>> HVM with PV drivers guest to a 64-bit hypervisor need to lie below
>> __HYPERVISOR_COMPAT_VIRT_START?  Both HVM and PVM domains have their
>> hv_compat_vstart set to __HYPERVISOR_COMPAT_VIRT_START.  The
>> hypervisor's compat layer is causing the balloon driver's
>> HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation)
>> hypervisor call to error out in xen/common/compat/memory.c
>> compat_memory_op(), compat_handle_ok(), because the PVHVM guest's
>> extent_start lies above __HYPERVISOR_COMPAT_VIRT_START.  The following
>> patch appears to fix the problem but I want to make sure it is fixing
>> the real bug:
> 
> Yeah, you pretty much have it figured. I may just clean up for style (I
> think an extra macro for this is a bit pointless), but the patch is
> fundamentally good.

Take a look at xen-unstable.hg:20101

 -- Keir

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers
  2009-08-20 17:37   ` Keir Fraser
@ 2009-08-20 20:48     ` Chuck Anderson
  0 siblings, 0 replies; 4+ messages in thread
From: Chuck Anderson @ 2009-08-20 20:48 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com

[-- Attachment #1: Type: text/html, Size: 1848 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-08-20 20:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-20 15:30 __HYPERVISOR_COMPAT_VIRT_START for HVM guest with PV drivers Chuck Anderson
2009-08-20 16:27 ` Keir Fraser
2009-08-20 17:37   ` Keir Fraser
2009-08-20 20:48     ` Chuck Anderson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.