|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 12/12] Nested Virtualization: hap-on-hap
>>> On 29.04.11 at 11:09, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
> On 04/29/11 11:03, Jan Beulich wrote:
>>>>> On 05.04.11 at 17:48, Christoph Egger<Christoph.Egger@xxxxxxx> wrote:
>>> diff -r cfde4384be14 -r 28809c365861 xen/include/asm-x86/domain.h
>>> --- a/xen/include/asm-x86/domain.h
>>> +++ b/xen/include/asm-x86/domain.h
>>> ...
>>> @@ -225,6 +227,7 @@ struct paging_vcpu {
>>> #define MAX_CPUID_INPUT 40
>>> typedef xen_domctl_cpuid_t cpuid_input_t;
>>>
>>> +#define MAX_NESTEDP2M 10
>>> struct p2m_domain;
>>> struct time_scale {
>>> int shift;
>>> @@ -258,6 +261,12 @@ struct arch_domain
>>> struct paging_domain paging;
>>> struct p2m_domain *p2m;
>>>
>>> + /* nestedhvm: translate l2 guest physical to host physical */
>>> + struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>>> + spinlock_t nested_p2m_lock;
>>> + int nested_p2m_locker;
>>> + const char *nested_p2m_function;
>>> +
>>> /* NB. protected by d->event_lock and by irq_desc[irq].lock */
>>> int *irq_pirq;
>>> int *pirq_irq;
>>
>> Was there a specific reason to add this to struct arch_domain
>> instead of struct hvm_domain? I.e. can any pf these fields be
>> used on pv (or idle) domains?
>
> The reason is that there is already a 'struct p2m_domain *p2m' field.
> If that can be moved to struct hvm_domain then nested_p2m can
> definitely move over to there, too.
No, I don't think these are connected - a pv domain can still require
a p2m (e.g. for the iommu), but I would have thought that the
nesting stuff doesn't apply there.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|