[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] C Macros and Xen RING Macros Questions



Thanks for the response.

On Sat, Apr 7, 2012 at 4:54 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Fri, Apr 06, 2012 at 07:20:13PM +0900, Daniel Castro wrote:
>> hello All,
>>
>> I am still working on the PV Drivers for SeaBIOS using upstream qemu.
>> And, I have two questions.
>> 1.
>> Here is the location of all relevant data structs:
>> blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000
>
> I surmise this is the guest PFNs.

Well this are virtual addresses seen by the BIOS on runtime.
>
>> DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
>> Here is my problem, when I do:
>>         ring_req =
>> GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLAT2GLOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
>>  //please ignore the MACROS for now, or read further down.
>> I get:
>> After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
>> But I have the feeling that the request should be between
>> 0x0009b000-0x000ab000. Right?
>
> That would imply a physical address - but if you are running with
> pagetables (which I think you are?) then it would be virtual address.
>
> You should have some basic macros to translate from virtual to physical
> and vice-versa.
I can do the usual bit wise operation to get the page.
>
>>
>> 2.
>> As you can see in the above code I use some SeaBIOS macros to access
>> 32Bit addresses in 16Bit code. My second questions is: How the memory
>
> 16-bit code. Refresh my memory - does that mean you can only
> use segments and no paging? So you need to move a 16-bit window
> around to get to your 32-bit address?
Yes, but Seabios allows you to use a special malloc so that you do not
neet to handle the segment directly, if done correctly you can wrap
the memory access on a MACRO that will set the memory access with the
segment selector, make the access, and change the result to a 32bit
format.
>
>> access macros affect the RING macros? Do I need to rewrite the ring
>> macros to use the memory macros inside, for example:
>
> It should fit within a 16-bit (64K) contingous memory space.
> I don't think it matters where that the block is - as long as you
> have a segment selector activated for that 16-bit block.
>
>> /* How big is this ring? */
>> #define RING_SIZE(_r)                                                   \
>>     ((_r)->nr_ents)
>
> That tells you just how many entries are on it. Not how big
> the structure is. For that it is sizeof(struct ..).
The problem on this particular case is this: (_r)->nr_ents; _r is a
pointer, if run in 16bit mode without the macros it will just be a an
offset, and since this is the BIOS there is no segmentation fault
generated, the BIOS allows me to make any access I want, even
incorrect ones.
I call this function like this: RING_SIZE(private_ring);
Where private_ring is a pointer created in 32bit mode, but is being
access with a 16bit address space. I can use the wrapper around the
pointer and make the Xen Macros call, but then I do not know if inside
the macros expansion it will be called under 32bit address or 16bit
address. For example:
Before the expansion
RING_SIZE(0x000d6200)                RING_SIZE(0x6200)
After the expansion
RING_SIZE((0x000d6200)->nr_ents)               RING_SIZE((0x6200)->nr_ents)
But here when the system does "->nr_ents" will this be done on 32bit
address or 16bit address? Clearly from the evidence it is doing it
under 16Bit address, hence my erratic answers.

I guess there could be a way to tell the compiler to expand the macro
with the use of the macros? or I am gust over complicating the problem
and I should directly rewrite the macros to include SeaBIOS macros?

One last explanation:
As I understand it, the macros works like this:
1. Set segment selector to appropriate value
2. make memory access
3. but return value on stack
4. set old value of segment selector
5. set value from stack on variable

variables on the stack can be considered 32bit.
>
>>
>> Should be instead:
>> /* How big is this ring? */
>> #define RING_SIZE(_r)                                                   \
>>     (GET_GLOBAL((_r)->nr_ents))
>>
>> SeaBIOS macros need to be around ALL memory accesses.
>>
>> This is a short message for something that might be to complex to
>> explain briefly, so please ask any questions that you deem necessary
>> to understand. Right now, I am developing the first stage of boot when
>> the BIOS requests address 7c00 to get the Boot sector. Once I get this
>> working we should have a working prototype for PV-drivers in seabios.
>>
>> Thank you all for your interest,
>>
>> Daniel
>>
>> --
>> +-=====---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |   | Daniel Castro,                |
>> | |   | Consultant/Programmer.|
>> | |   | U Andes                         |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.