Can anyone please tell me what was the xen version in which struct vcpu_info was not present? Should I see in xen 2.0 ?...I need a xen version without "struct vcpu_info" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s worth a shot looking there. Certainly 3+ will have it for sure. Is there a particular reason you want to avoid that struct? -George On Fri, Oct 10, 2008 at 1:37 PM, pallavi jk <pallutai@gmail.com> wrote:> Can anyone please tell me what was the xen version in which struct vcpu_info > was not present? > > Should I see in xen 2.0 ?...I need a xen version without "struct vcpu_info" > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanx George. Yes, am looking into xen-2.0. "struct vcpu_info" is not present there. Actually am doing a project in which i need to provide a functionality similar to pushing the address of cr2 onto the stack. Also, how can I avoid the use of fast handlers?...I need to perform some checks inside xen before transferring control to the guest OS for each trap. Should I modify the "set_trap_table" hypercall for that?? On Fri, Oct 10, 2008 at 6:15 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote:> It''s worth a shot looking there. Certainly 3+ will have it for sure. > > Is there a particular reason you want to avoid that struct? > > -George > > On Fri, Oct 10, 2008 at 1:37 PM, pallavi jk <pallutai@gmail.com> wrote: > > Can anyone please tell me what was the xen version in which struct > vcpu_info > > was not present? > > > > Should I see in xen 2.0 ?...I need a xen version without "struct > vcpu_info" > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
pallavi jk wrote:> Thanx George. > > Yes, am looking into xen-2.0. "struct vcpu_info" is not present there. > > Actually am doing a project in which i need to provide a functionality > similar to pushing the address of cr2 onto the stack. > > Also, how can I avoid the use of fast handlers?...I need to perform > some checks inside xen before transferring control to the guest OS for > each trap. > > Should I modify the "set_trap_table" hypercall for that??It might help if you give a more complete description of what you''re trying to achieve. The list of things you''re trying to do or want don''t make a lot of sense on their own. For example, are you modifying Xen? Or just guest code? If you''re modifying Xen, it''s pretty easy to remove the special case for trap 0x80. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Jeremy, Yes, I am planning to modify xen and the guest OS as well. I need to trap every entry into the guest OS from user mode because I need to perform some checks in the hypervisor before transferring control to the guest OS. So I need to avoid fast handlers which would directly transfer control to the guest OS, as I want to trap this entry first in the hypervisor. I need to do this as I intend to protect applications from a possibly malicious OS, so I want to perform some checks in the hypervisor. I have just started studying the code. Can you please provide me guidelines about which source files and functions I should concentrate on? On Fri, Oct 10, 2008 at 10:10 PM, Jeremy Fitzhardinge <jeremy@goop.org>wrote:> pallavi jk wrote: > >> Thanx George. >> >> Yes, am looking into xen-2.0. "struct vcpu_info" is not present there. >> >> Actually am doing a project in which i need to provide a functionality >> similar to pushing the address of cr2 onto the stack. >> >> Also, how can I avoid the use of fast handlers?...I need to perform some >> checks inside xen before transferring control to the guest OS for each trap. >> >> Should I modify the "set_trap_table" hypercall for that?? >> > > It might help if you give a more complete description of what you''re trying > to achieve. The list of things you''re trying to do or want don''t make a lot > of sense on their own. > > For example, are you modifying Xen? Or just guest code? If you''re > modifying Xen, it''s pretty easy to remove the special case for trap 0x80. > > J >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
pallavi jk wrote:> Hi Jeremy, > > Yes, I am planning to modify xen and the guest OS as well. > > I need to trap every entry into the guest OS from user mode because I > need to perform some checks in the hypervisor before transferring > control to the guest OS.If you run a 64-bit hypervisor, this will happen automatically. Only 32-on-32 supports directly trapping from guest usermode to kernel.> So I need to avoid fast handlers which would directly transfer control > to the guest OS, as I want to trap this entry first in the hypervisor. > I need to do this as I intend to protect applications from a possibly > malicious OS, so I want to perform some checks in the hypervisor. > > I have just started studying the code. Can you please provide me > guidelines about which source files and functions I should concentrate > on?arch/x86/**/traps.c is the first point to look at. Also entry.S which does the actual transfer of control between the various modes. There are several variants of each file for different modes (32, 64, 32 compat on 64), so make sure you target the right ones. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanx a lot Jeremy!! This is really going to be a lot of help. Right now I am not very sure whether I will be able to use a 64-bit machine, but I will consider that options. Thanx again for the help. On Fri, Oct 10, 2008 at 10:56 PM, Jeremy Fitzhardinge <jeremy@goop.org>wrote:> pallavi jk wrote: > >> Hi Jeremy, >> >> Yes, I am planning to modify xen and the guest OS as well. >> >> I need to trap every entry into the guest OS from user mode because I need >> to perform some checks in the hypervisor before transferring control to the >> guest OS. >> > > If you run a 64-bit hypervisor, this will happen automatically. Only > 32-on-32 supports directly trapping from guest usermode to kernel. > > So I need to avoid fast handlers which would directly transfer control to >> the guest OS, as I want to trap this entry first in the hypervisor. I need >> to do this as I intend to protect applications from a possibly malicious OS, >> so I want to perform some checks in the hypervisor. >> >> I have just started studying the code. Can you please provide me >> guidelines about which source files and functions I should concentrate on? >> > > arch/x86/**/traps.c is the first point to look at. Also entry.S which does > the actual transfer of control between the various modes. There are several > variants of each file for different modes (32, 64, 32 compat on 64), so make > sure you target the right ones. > > J >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel