Little help with Seabios PV-Drivers for XEN

Little help with Seabios PV-Drivers for XEN

[Daniel Castro]

Hello All,

I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
The initialization code that runs in 32 Bit is working properly.
But, when the system tries to read on the disk I use the ring macros
to get a request. The macro usage looks like this:
struct blkif_ring * shared = memalign_low(4096,4096); //return
0x000fd630 this above 16bit address space
SHARED_RING_INIT(shared);
So far I have a pointer located at 0x0009a000
Under 32bit the struct is correct and all is working according to plan.

But on 16bit operation read on disk I have
struct blkfront_info * shared_ring =
container_of(op->drive_g.info->shared)); // I get d630 I should get it
from the correct segment, but how?
RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
something 0xa010 segment SS or something like that

SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
changing the segment register, yet I do not know in what segment the
ring is located, and the macros are not applied inside the procedure
of the macro, for example:
MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
But this will change a 16Bit pointer of segment SS to a 32 bit
segment. There is also the reverse but, again I do not know the
segment in which I should look for. Lastly the process inside the
macro does not get this benefin, and I do not know if the macro will
work with a pointer of size 16bits.

Any help will be GREATLY appreciated, I am almost done.

Thanks,

Daniel
-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

Re: Little help with Seabios PV-Drivers for XEN

[James Harper]

> Hello All,
> 
> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
> The initialization code that runs in 32 Bit is working properly.
> But, when the system tries to read on the disk I use the ring macros to get a
> request. The macro usage looks like this:
> struct blkif_ring * shared = memalign_low(4096,4096); //return
> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
> far I have a pointer located at 0x0009a000 Under 32bit the struct is correct
> and all is working according to plan.
> 
> But on 16bit operation read on disk I have struct blkfront_info * shared_ring
> = container_of(op->drive_g.info->shared)); // I get d630 I should get it from
> the correct segment, but how?
> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
> something 0xa010 segment SS or something like that

Just curios, does 16 bit include the required atomic instructions to manipulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit mode and only accessing the requests already retrieved from the ring in 16 bit mode?

> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by changing
> the segment register, yet I do not know in what segment the ring is located,
> and the macros are not applied inside the procedure of the macro, for
> example:
> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
> But this will change a 16Bit pointer of segment SS to a 32 bit segment. There
> is also the reverse but, again I do not know the segment in which I should
> look for. Lastly the process inside the macro does not get this benefin, and I
> do not know if the macro will work with a pointer of size 16bits.
> 
> Any help will be GREATLY appreciated, I am almost done.
> 

I'm not sure if this would be useful, but is there a way to hand over the ring to the OS PV drivers and avoid the teardown/setup?

James

Re: Little help with Seabios PV-Drivers for XEN

[Daniel Castro]

On Fri, Mar 9, 2012 at 8:59 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros to get a
>> request. The macro usage looks like this:
>> struct blkif_ring * shared = memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
>> far I have a pointer located at 0x0009a000 Under 32bit the struct is correct
>> and all is working according to plan.
>>
>> But on 16bit operation read on disk I have struct blkfront_info * shared_ring
>> = container_of(op->drive_g.info->shared)); // I get d630 I should get it from
>> the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>
> Just curios, does 16 bit include the required atomic instructions to manipulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit mode and only accessing the requests already retrieved from the ring in 16 bit mode?\
I think that is the problem, the operations inside the macro do not
take into account that they are being executed in a 16bit environment.
>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by changing
>> the segment register, yet I do not know in what segment the ring is located,
>> and the macros are not applied inside the procedure of the macro, for
>> example:
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit segment. There
>> is also the reverse but, again I do not know the segment in which I should
>> look for. Lastly the process inside the macro does not get this benefin, and I
>> do not know if the macro will work with a pointer of size 16bits.
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>
> I'm not sure if this would be useful, but is there a way to hand over the ring to the OS PV drivers and avoid the teardown/setup?
I am not sure that I undestand you, all this is exectuted when the
domain builder is deploying the hvmloader. The next step once the
PV-Drivers work is the shutdown sequence to and proper preparation for
the OS "arrival" (meaning boot seq).
>
> James
>



-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

Re: Little help with Seabios PV-Drivers for XEN

[Daniel Castro]

Yes, out of sync, anyway...

On Fri, Mar 9, 2012 at 8:59 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros to get a
>> request. The macro usage looks like this:
>> struct blkif_ring * shared = memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
>> far I have a pointer located at 0x0009a000 Under 32bit the struct is correct
>> and all is working according to plan.
>>
>> But on 16bit operation read on disk I have struct blkfront_info * shared_ring
>> = container_of(op->drive_g.info->shared)); // I get d630 I should get it from
>> the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>
> Just curios, does 16 bit include the required atomic instructions to manipulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit mode and only accessing the requests already retrieved from the ring in 16 bit mode?
This is my current problem, when I do
RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->private->req_prod_pvt));
The return address is incorrect, so I guess since inside the
RING_REQUEST MACRO I make memory access I will need to rewrite the
macro to include the SeaBios macros needed to address 32bit pointers
in 16bit mode.
>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by changing
>> the segment register, yet I do not know in what segment the ring is located,
>> and the macros are not applied inside the procedure of the macro, for
>> example:
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit segment. There
>> is also the reverse but, again I do not know the segment in which I should
>> look for. Lastly the process inside the macro does not get this benefin, and I
>> do not know if the macro will work with a pointer of size 16bits.
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>
> I'm not sure if this would be useful, but is there a way to hand over the ring to the OS PV drivers and avoid the teardown/setup?
This is before there is an OS. The bios handles the boot process,
right now I am trying to get the first read on the drive, the boot
sector.
>
> James
>



-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

Re: Little help with Seabios PV-Drivers for XEN

[Konrad Rzeszutek Wilk]

On Sat, Apr 07, 2012 at 08:01:14PM +0900, Daniel Castro wrote:
> Yes, out of sync, anyway...
> 
> On Fri, Mar 9, 2012 at 8:59 AM, James Harper
> <james.harper@bendigoit.com.au> wrote:
> >> Hello All,
> >>
> >> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
> >> The initialization code that runs in 32 Bit is working properly.
> >> But, when the system tries to read on the disk I use the ring macros to get a
> >> request. The macro usage looks like this:
> >> struct blkif_ring * shared = memalign_low(4096,4096); //return
> >> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
> >> far I have a pointer located at 0x0009a000 Under 32bit the struct is correct
> >> and all is working according to plan.
> >>
> >> But on 16bit operation read on disk I have struct blkfront_info * shared_ring
> >> = container_of(op->drive_g.info->shared)); // I get d630 I should get it from
> >> the correct segment, but how?
> >> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
> >> something 0xa010 segment SS or something like that
> >
> > Just curios, does 16 bit include the required atomic instructions to manipulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit mode and only accessing the requests already retrieved from the ring in 16 bit mode?
> This is my current problem, when I do
> RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->private->req_prod_pvt));
> The return address is incorrect, so I guess since inside the
> RING_REQUEST MACRO I make memory access I will need to rewrite the
> macro to include the SeaBios macros needed to address 32bit pointers
> in 16bit mode.

Which is
/* Direct access to individual ring elements, by index. */
#define RING_GET_REQUEST(_r, _idx)                                      \
    (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))


?
I would try to not use macros at the start to unravel any
complexity.

Did GET_GLOBAL(blk_info->private) get you a valid pointer? If
you do a hexdump of that area do you get what you expect?

> >
> >> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by changing
> >> the segment register, yet I do not know in what segment the ring is located,
> >> and the macros are not applied inside the procedure of the macro, for
> >> example:
> >> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
> >> But this will change a 16Bit pointer of segment SS to a 32 bit segment. There
> >> is also the reverse but, again I do not know the segment in which I should
> >> look for. Lastly the process inside the macro does not get this benefin, and I
> >> do not know if the macro will work with a pointer of size 16bits.
> >>
> >> Any help will be GREATLY appreciated, I am almost done.
> >>
> >
> > I'm not sure if this would be useful, but is there a way to hand over the ring to the OS PV drivers and avoid the teardown/setup?
> This is before there is an OS. The bios handles the boot process,
> right now I am trying to get the first read on the drive, the boot
> sector.
> >
> > James
> >
> 
> 
> 
> -- 
> +-=====---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |   | Daniel Castro,                |
> | |   | Consultant/Programmer.|
> | |   | U Andes                         |
> +-------------------------------------+
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Little help with Seabios PV-Drivers for XEN

[Konrad Rzeszutek Wilk]

On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
> Hello All,
> 
> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.

Hey, seems I read your emails out of sync.

> The initialization code that runs in 32 Bit is working properly.
> But, when the system tries to read on the disk I use the ring macros
> to get a request. The macro usage looks like this:
> struct blkif_ring * shared = memalign_low(4096,4096); //return
> 0x000fd630 this above 16bit address space
> SHARED_RING_INIT(shared);
> So far I have a pointer located at 0x0009a000
> Under 32bit the struct is correct and all is working according to plan.
> 
> But on 16bit operation read on disk I have
> struct blkfront_info * shared_ring =
> container_of(op->drive_g.info->shared)); // I get d630 I should get it
> from the correct segment, but how?
> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
> something 0xa010 segment SS or something like that
> 
> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
> changing the segment register, yet I do not know in what segment the
> ring is located, and the macros are not applied inside the procedure
> of the macro, for example:

There should be some way to set your physical address (so
9a000) to a segment?

> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
> But this will change a 16Bit pointer of segment SS to a 32 bit
> segment. There is also the reverse but, again I do not know the
> segment in which I should look for. Lastly the process inside the
> macro does not get this benefin, and I do not know if the macro will
> work with a pointer of size 16bits.

16-bits should be fine. The problem is if you run your pointer
outside the 16-bit segment.

> 
> Any help will be GREATLY appreciated, I am almost done.
> 
> Thanks,
> 
> Daniel
> -- 
> +-=====---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |   | Daniel Castro,                |
> | |   | Consultant/Programmer.|
> | |   | U Andes                         |
> +-------------------------------------+
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Little help with Seabios PV-Drivers for XEN

[Daniel Castro]

On Sat, Apr 7, 2012 at 5:34 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in SeaBIOS.
>
> Hey, seems I read your emails out of sync.
>
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros
>> to get a request. The macro usage looks like this:
>> struct blkif_ring * shared = memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space
>> SHARED_RING_INIT(shared);
>> So far I have a pointer located at 0x0009a000
>> Under 32bit the struct is correct and all is working according to plan.
>>
>> But on 16bit operation read on disk I have
>> struct blkfront_info * shared_ring =
>> container_of(op->drive_g.info->shared)); // I get d630 I should get it
>> from the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
>> changing the segment register, yet I do not know in what segment the
>> ring is located, and the macros are not applied inside the procedure
>> of the macro, for example:
>
> There should be some way to set your physical address (so
> 9a000) to a segment?
>
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit
>> segment. There is also the reverse but, again I do not know the
>> segment in which I should look for. Lastly the process inside the
>> macro does not get this benefin, and I do not know if the macro will
>> work with a pointer of size 16bits.
>
> 16-bits should be fine. The problem is if you run your pointer
> outside the 16-bit segment.
Thanks for the response Konrad, Seabios provides some macross that
will set the segment automatically, you only need to use a specific
malloc to get the memory; For example:
int * pointer VAR16VISIBLE;
pointer = mallow_low(sizeof(pointer));
This code will create the pointer in a specific segment, so later when I use:
printf("%p",GET_GLOBALFLAT(pointer)); This will return the 32bit
address of it, If I do not use the GET_GLOBAL macro I will only get
the offset on the segment.
>
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>> Thanks,
>>
>> Daniel
>> --
>> +-=====---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |   | Daniel Castro,                |
>> | |   | Consultant/Programmer.|
>> | |   | U Andes                         |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+