vcpu_info

vcpu_info

[pallavi jk]

[-- Attachment #1.1: Type: text/plain, Size: 171 bytes --]

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"

[-- Attachment #1.2: Type: text/html, Size: 212 bytes --]

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

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

Re: vcpu_info

[George Dunlap]

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
>
>

Re: vcpu_info

[pallavi jk]

[-- Attachment #1.1: Type: text/plain, Size: 1090 bytes --]

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
> >
> >
>

[-- Attachment #1.2: Type: text/html, Size: 1725 bytes --]

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

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

Re: vcpu_info

[Jeremy Fitzhardinge]

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

Re: vcpu_info

[pallavi jk]

[-- Attachment #1.1: Type: text/plain, Size: 1550 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2120 bytes --]

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

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

Re: vcpu_info

[Jeremy Fitzhardinge]

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

Re: vcpu_info

[pallavi jk]

[-- Attachment #1.1: Type: text/plain, Size: 1427 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2115 bytes --]

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

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