Tian, Kevin
2007-Jan-15 06:31 UTC
[Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
Curious about "HVM compat" here? :-) I can''t get exact meaning simply by following change. Is it an exact new model, since 32bit HVM guests are already supported on 64bit xen? Or it means a compat-dom0 coupled with 32bit HVM? Or something like to reuse new compat layer for HVM side if translation required? Thanks, Kevin>-----Original Message----- >From: xen-changelog-bounces@lists.xensource.com >[mailto:xen-changelog-bounces@lists.xensource.com] On Behalf Of Xen >patchbot-unstable >Sent: 2007年1月6日 4:56 >To: xen-changelog@lists.xensource.com >Subject: [Xen-changelog] [xen-unstable] Initial support for HVM compat >guests > ># HG changeset patch ># User Emmanuel Ackaouy <ack@xensource.com> ># Date 1168019467 0 ># Node ID 23dcc167b97efba1c81c51bd0d6adb094c80d013 ># Parent 1b7ebd25fa40cf603910f1ffc7d59eba03050da1 >Initial support for HVM compat guests > >Signed-off-by: Emmanuel Ackaouy <ack@xensource.com> >--- > xen/arch/x86/domain.c | 6 +++++- > xen/arch/x86/hvm/intercept.c | 2 +- > xen/arch/x86/mm/shadow/multi.c | 1 - > xen/arch/x86/x86_64/compat/entry.S | 4 ++-- > xen/include/public/hvm/ioreq.h | 5 +++-- > 5 files changed, 11 insertions(+), 7 deletions(-) > >diff -r 1b7ebd25fa40 -r 23dcc167b97e xen/arch/x86/domain.c >--- a/xen/arch/x86/domain.c Fri Jan 05 17:46:14 2007 +0000 >+++ b/xen/arch/x86/domain.c Fri Jan 05 17:51:07 2007 +0000 >@@ -1395,7 +1395,11 @@ void domain_relinquish_resources(struct > #ifdef CONFIG_COMPAT > if ( IS_COMPAT(d) ) > { >- pfn = l4e_get_pfn(*(l4_pgentry_t >*)__va(pagetable_get_paddr(v->arch.guest_table))); >+ if ( is_hvm_vcpu(v) ) >+ pfn = pagetable_get_pfn(v->arch.guest_table); >+ else >+ pfn = l4e_get_pfn(*(l4_pgentry_t >*)__va(pagetable_get_paddr(v->arch.guest_table))); >+ > if ( pfn != 0 ) > { > if ( shadow_mode_refcounts(d) ) >diff -r 1b7ebd25fa40 -r 23dcc167b97e xen/arch/x86/hvm/intercept.c >--- a/xen/arch/x86/hvm/intercept.c Fri Jan 05 17:46:14 2007 +0000 >+++ b/xen/arch/x86/hvm/intercept.c Fri Jan 05 17:51:07 2007 +0000 >@@ -182,7 +182,7 @@ int hvm_buffered_io_intercept(ioreq_t *p > spin_lock(buffered_io_lock); > > if ( buffered_iopage->write_pointer - >buffered_iopage->read_pointer =>- (unsigned long)IOREQ_BUFFER_SLOT_NUM ) { >+ (unsigned int)IOREQ_BUFFER_SLOT_NUM ) { > /* the queue is full. > * send the iopacket through the normal path. > * NOTE: The arithimetic operation could handle the situation >for >diff -r 1b7ebd25fa40 -r 23dcc167b97e xen/arch/x86/mm/shadow/multi.c >--- a/xen/arch/x86/mm/shadow/multi.c Fri Jan 05 17:46:14 2007 +0000 >+++ b/xen/arch/x86/mm/shadow/multi.c Fri Jan 05 17:51:07 2007 >+0000 >@@ -2106,7 +2106,6 @@ void sh_destroy_monitor_table(struct vcp > shadow_free(d, _mfn(l3e_get_pfn(l3e[3]))); > sh_unmap_domain_page(l3e); > } >- shadow_free(d, mmfn); > sh_unmap_domain_page(l4e); > } > #elif CONFIG_PAGING_LEVELS == 3 >diff -r 1b7ebd25fa40 -r 23dcc167b97e >xen/arch/x86/x86_64/compat/entry.S >--- a/xen/arch/x86/x86_64/compat/entry.S Fri Jan 05 17:46:14 2007 >+0000 >+++ b/xen/arch/x86/x86_64/compat/entry.S Fri Jan 05 17:51:07 >2007 +0000 >@@ -313,7 +313,7 @@ ENTRY(compat_hypercall_table) > .quad compat_xenoprof_op > .quad do_event_channel_op > .quad compat_physdev_op >- .quad compat_ni_hypercall >+ .quad do_hvm_op > .quad compat_sysctl /* 35 */ > .quad compat_domctl > .quad compat_kexec_op >@@ -356,7 +356,7 @@ ENTRY(compat_hypercall_args_table) > .byte 2 /* compat_xenoprof_op */ > .byte 2 /* compat_event_channel_op */ > .byte 2 /* compat_physdev_op */ >- .byte 0 /* compat_ni_hypercall */ >+ .byte 2 /* do_hvm_op */ > .byte 1 /* compat_sysctl */ /* 35 */ > .byte 1 /* compat_domctl */ > .byte 2 /* compat_kexec_op */ >diff -r 1b7ebd25fa40 -r 23dcc167b97e xen/include/public/hvm/ioreq.h >--- a/xen/include/public/hvm/ioreq.h Fri Jan 05 17:46:14 2007 +0000 >+++ b/xen/include/public/hvm/ioreq.h Fri Jan 05 17:51:07 2007 +0000 >@@ -56,6 +56,7 @@ struct ioreq { > uint8_t dir:1; /* 1=read, 0=write */ > uint8_t df:1; > uint8_t type; /* I/O type */ >+ uint8_t _pad0[6]; > uint64_t io_count; /* How many IO done on a vcpu */ > }; > typedef struct ioreq ioreq_t; >@@ -74,8 +75,8 @@ typedef struct shared_iopage shared_iopa > > #define IOREQ_BUFFER_SLOT_NUM 80 > struct buffered_iopage { >- unsigned long read_pointer; >- unsigned long write_pointer; >+ unsigned int read_pointer; >+ unsigned int write_pointer; > ioreq_t ioreq[IOREQ_BUFFER_SLOT_NUM]; > }; /* sizeof this structure must be in one page */ > typedef struct buffered_iopage buffered_iopage_t; > >_______________________________________________ >Xen-changelog mailing list >Xen-changelog@lists.xensource.com >http://lists.xensource.com/xen-changelog_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jan-15 07:43 UTC
Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
On 15/1/07 6:31 am, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Or it means a > compat-dom0 coupled with 32bit HVM? Or something like to reuse > new compat layer for HVM side if translation required?Both of the above. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2007-Jan-15 08:07 UTC
RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2007年1月15日 15:43 > >On 15/1/07 6:31 am, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> Or it means a >> compat-dom0 coupled with 32bit HVM? Or something like to reuse >> new compat layer for HVM side if translation required? > >Both of the above. > > -- KeirSo is this still on development for HVM? I didn''t find where _DOMF_COMPAT is set for 32bit HVM guest, and then compat logic under is_hvm_vcpu may not make effect yet. (Correct me if I''m wrong) Other incompleteness is like, XLAT_cpu_user_regs is invoked after hvm_store_cpu_guest_regs in arch_get_info_guest, while arch_set_info_guest invokes hvm_load_cpu_guest_regs directly, etc. Also, one question is whether COMPAT mode requires all guests to be in compatible, or can be mixed like 64bit dom0 + 32bit domU. Still take arch_get_info_guest for example: Vcpu_guest_context is translated if target domain is compat mode, while there''s no check for current domain''s mode. Then compat context is copied back to dom0 even when dom0 is a 64bit guest. Are things like above deliberately made to depend on dom0 aware of target guest context layout, or something still immature? I just want to get a clear picture what impact this new compatible mode may bring to the whole environment. :-) Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jan-15 08:16 UTC
Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
On 15/1/07 8:07 am, "Tian, Kevin" <kevin.tian@intel.com> wrote:> So is this still on development for HVM? I didn''t find where > _DOMF_COMPAT is set for 32bit HVM guest, and then compat > logic under is_hvm_vcpu may not make effect yet. (Correct me if > I''m wrong)An HVM guest does not use DOMF_COMPAT. You can deduce its execution mode from CS attribute bytes. And of course it can switch execution mode back and forth as it runs, and on different VCPUs, etc.> Other incompleteness is like, XLAT_cpu_user_regs is invoked > after hvm_store_cpu_guest_regs in arch_get_info_guest, while > arch_set_info_guest invokes hvm_load_cpu_guest_regs directly, > etc.Yes, that''s an incompleteness. Stuff is getting implemented on demand. Noone uses arch_set_info_guest() on an HVM guest, but xc_ptrace() does use arch_get_info_guest() so I guess Jan fixed that one up.> Also, one question is whether COMPAT mode requires all guests > to be in compatible, or can be mixed like 64bit dom0 + 32bit domU. > Still take arch_get_info_guest for example: > Vcpu_guest_context is translated if target domain is compat > mode, while there''s no check for current domain''s mode. Then > compat context is copied back to dom0 even when dom0 is a 64bit > guest.Currently we require all guests to be in the same mode. However, there are tools changes in progress to allow mixed-mode guests. Checking COMPAT of caller vs. target is indeed a bit confusing. We''ll audit the domctl interfaces and make up our mind how that should work when we apply the tools changes for mixed-mode guests.> Are things like above deliberately made to depend on dom0 aware > of target guest context layout, or something still immature? I just want > to get a clear picture what impact this new compatible mode may bring > to the whole environment. :-)dom0 must be aware of target guest context. It builds the page tables for example. :-) So it is acceptable for him to have to use different domctl() commands to initialise 32- vs 64-bit pv guests (although we obviously want to avoid bloating the interface with compat crap as far as possible). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2007-Jan-15 08:31 UTC
RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2007年1月15日 16:17 > >On 15/1/07 8:07 am, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> So is this still on development for HVM? I didn''t find where >> _DOMF_COMPAT is set for 32bit HVM guest, and then compat >> logic under is_hvm_vcpu may not make effect yet. (Correct me if >> I''m wrong) > >An HVM guest does not use DOMF_COMPAT. You can deduce its >execution mode >from CS attribute bytes. And of course it can switch execution mode >back and >forth as it runs, and on different VCPUs, etc.So what''s the proposed way to reuse compat code for HVM guest? Extend IS_COMPAT() to cover HVM domain even when DOMF_COMPAT is not set, or invoke compatible layer directly when required. In any case, I just didn''t see why IS_COMPAT() branch is placed under is_hvm_vcpu for now. :-) Thanks for you kind answer on other questions. - Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jan-15 08:38 UTC
Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
On 15/1/07 8:31 am, "Tian, Kevin" <kevin.tian@intel.com> wrote:>> An HVM guest does not use DOMF_COMPAT. You can deduce its >> execution mode >> from CS attribute bytes. And of course it can switch execution mode >> back and >> forth as it runs, and on different VCPUs, etc. > > So what''s the proposed way to reuse compat code for HVM guest? > Extend IS_COMPAT() to cover HVM domain even when > DOMF_COMPAT is not set, or invoke compatible layer directly when > required. In any case, I just didn''t see why IS_COMPAT() branch is > placed under is_hvm_vcpu for now. :-)Hmmm there is underlying code shared by both compat and native hypercall layer that will check IS_COMPAT. So jumping at the compat layer is insufficient (even though that is precisely what the hvm hypercall wrapper does). Basically this work isn''t complete yet. Probably what will happen is that the IS_COMPAT() test will be made per-vcpu rather than per-domain and we will set the per-vcpu flag correctly for an hvm guest at least whenever it vmexits for a hypercall. Or we will make IS_COMPAT() look at shadow-mode guest_levels if it is invoked on an HVM vcpu. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2007-Jan-15 08:57 UTC
RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2007年1月15日 16:39 > >Hmmm there is underlying code shared by both compat and native >hypercall >layer that will check IS_COMPAT. So jumping at the compat layer is >insufficient (even though that is precisely what the hvm hypercall >wrapper >does). > >Basically this work isn''t complete yet. Probably what will happen is that >the IS_COMPAT() test will be made per-vcpu rather than per-domain and >we >will set the per-vcpu flag correctly for an hvm guest at least whenever it >vmexits for a hypercall. Or we will make IS_COMPAT() look at >shadow-mode >guest_levels if it is invoked on an HVM vcpu. > > -- KeirOK, the status is clearer to me now. Thanks a lot, - Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel