Xen devel - Jul 2009 - How is the virt_hv_start_low used in compatible guest

Jan/Keir, I have a question to followin code In arch/x86/domain_build.c. Can you
share me why we need to make the virt_start be adjustable based on the memory
size in the system? Per my understanding, these changes will only affect HV
itself, but I didn''t see much benifit. Or did I missed anything?

Thanks
Yunhong Jiang

    if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf)
)
    {
        unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1;
        value = (parms.virt_hv_start_low + mask) & ~mask;
        BUG_ON(!is_pv_32bit_domain(d));
#if defined(__i386__)
        if ( value > HYPERVISOR_VIRT_START )
            panic("Domain 0 expects too high a hypervisor start
address.\n");
#else
        if ( value > __HYPERVISOR_COMPAT_VIRT_START )
            panic("Domain 0 expects too high a hypervisor start
address.\n");
        HYPERVISOR_COMPAT_VIRT_START(d)             max_t(unsigned int,
m2p_compat_vstart, value);
#endif
    }

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

The guest can (and is actually doing so in the Dom0 case) make use of this e.g.
for setting the low/highmem boundary at a higher address, thus increasing the
amount of lowmem over what that would be on a 32-bit hypervisor. For DomU-s to
also benefit, the tools would need to be adjusted, but as this can affect where
a guest can be migrated to, so far it didn''t seem worthwhile for
anybody to actually implement this.

Jan
>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 06.07.09
11:20 >>>
Jan/Keir, I have a question to followin code In arch/x86/domain_build.c. Can you
share me why we need to make the virt_start be adjustable based on the memory
size in the system? Per my understanding, these changes will only affect HV
itself, but I didn''t see much benifit. Or did I missed anything?

Thanks
Yunhong Jiang

    if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf)
)
    {
        unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1;
        value = (parms.virt_hv_start_low + mask) & ~mask;
        BUG_ON(!is_pv_32bit_domain(d));
#if defined(__i386__)
        if ( value > HYPERVISOR_VIRT_START )
            panic("Domain 0 expects too high a hypervisor start
address.\n");
#else
        if ( value > __HYPERVISOR_COMPAT_VIRT_START )
            panic("Domain 0 expects too high a hypervisor start
address.\n");
        HYPERVISOR_COMPAT_VIRT_START(d)             max_t(unsigned int,
m2p_compat_vstart, value);
#endif
    }


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

Thanks for your answer very much.
When consider the memory add situation, the size can''t be adjusted, so
I disable this adjustment if we support memory add, do you think it is ok?

Thanks
Yunhong Jiang

Jan Beulich wrote:
> The guest can (and is actually doing so in the Dom0 case) make
> use of this e.g. for setting the low/highmem boundary at a
> higher address, thus increasing the amount of lowmem over what
> that would be on a 32-bit hypervisor. For DomU-s to also
> benefit, the tools would need to be adjusted, but as this can
> affect where a guest can be migrated to, so far it didn''t seem
> worthwhile for anybody to actually implement this.
> 
> Jan
> 
>>>> "Jiang, Yunhong" <yunhong.jiang@intel.com>
06.07.09 11:20 >>>
> Jan/Keir, I have a question to followin code In
> arch/x86/domain_build.c. Can you share me why we need to make
> the virt_start be adjustable based on the memory size in the
> system? Per my understanding, these changes will only affect
> HV itself, but I didn''t see much benifit. Or did I missed
anything?
> 
> Thanks
> Yunhong Jiang
> 
>    if ( (parms.virt_hv_start_low != UNSET_ADDR) &&
elf_32bit(&elf) )
>        { unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1;
>        value = (parms.virt_hv_start_low + mask) & ~mask;
>        BUG_ON(!is_pv_32bit_domain(d));
> #if defined(__i386__)
>        if ( value > HYPERVISOR_VIRT_START )
>            panic("Domain 0 expects too high a hypervisor
> start address.\n");
> #else
>        if ( value > __HYPERVISOR_COMPAT_VIRT_START )
>            panic("Domain 0 expects too high a hypervisor
> start address.\n");
>        HYPERVISOR_COMPAT_VIRT_START(d) >            max_t(unsigned int,
m2p_compat_vstart, value); #endif
>    }
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 07/08/09
9:22 AM >>>
>When consider the memory add situation, the size can''t be
>adjusted, so I disable this adjustment if we support memory
>add, do you think it is ok? 
I wouldn''t welcome this - instead, the maximum range of
memory ever expected to be added should be controlled by a
command line option for that purpose. And even without such,
instead of completely avoiding the adjustment, it should be
done assuming the maximum amount a 32-bit domain would
ever get to see (128Gb), which would still make the hole
smaller than it is on a 32-bit hv.

Jan

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

On 09/07/2009 08:24, "Jan Beulich" <jbeulich@novell.com> wrote:
>>>> "Jiang, Yunhong" <yunhong.jiang@intel.com>
07/08/09 9:22 AM >>>
>> When consider the memory add situation, the size can''t be
>> adjusted, so I disable this adjustment if we support memory
>> add, do you think it is ok?
> 
> I wouldn''t welcome this - instead, the maximum range of
> memory ever expected to be added should be controlled by a
> command line option for that purpose. And even without such,
> instead of completely avoiding the adjustment, it should be
> done assuming the maximum amount a 32-bit domain would
> ever get to see (128Gb), which would still make the hole
> smaller than it is on a 32-bit hv.
We agreed for now to size the hole big enough for amount of memory visible
at boot time, and compat dom0 will simply be unable to be allocated
dynamically added memory. It is at least not a regression of existing
support for compat dom0. We can do smarter things later if someone really
cares about the limitations of this scenario.

 -- Keir



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

Keir Fraser wrote:
> On 09/07/2009 08:24, "Jan Beulich" <jbeulich@novell.com>
wrote:
> 
>>>>> "Jiang, Yunhong" <yunhong.jiang@intel.com>
07/08/09 9:22 AM >>>
>>> When consider the memory add situation, the size can''t be
>>> adjusted, so I disable this adjustment if we support memory
>>> add, do you think it is ok?
>> 
>> I wouldn''t welcome this - instead, the maximum range of
>> memory ever expected to be added should be controlled by a
>> command line option for that purpose. And even without such,
>> instead of completely avoiding the adjustment, it should be
>> done assuming the maximum amount a 32-bit domain would
>> ever get to see (128Gb), which would still make the hole
>> smaller than it is on a 32-bit hv.
> 
> We agreed for now to size the hole big enough for amount of
> memory visible
> at boot time, and compat dom0 will simply be unable to be allocated
> dynamically added memory. It is at least not a regression of existing
> support for compat dom0. We can do smarter things later if
> someone really
> cares about the limitations of this scenario.
> 
> -- Keir
Yes, heere I made a mistake and Keir has pointed out.

Originally I thought dom0 will check the read-only m2p table for page that is
assigned to other guest, either for foreign mapping or granting. Later Keir told
me that the m2p table is only used for a domain''s own pages. Then it is
ok to leave the hole to contain memory that exist when booting, since page
allocator has take consideration of the hole size also for compatible guest.

But I did meet dom0''s bug if I didn''t increase the hole size
in compat dom0, so I need investigate the reason for it (originally I thought it
is caused by the read-only m2p table size).

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