Xen devel - Sep 2005 - [PATCH][VT]vga acceleration for cirrus logic device model

This patch add VGA acceleration support for cirrus logic device model.
It works on 32 guest under 32/64 host env.

Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Asit Mallick  <asit.k.mallick@intel.com>


Thanks
Yunhong Jiang


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

On 23 Sep 2005, at 10:25, Jiang, Yunhong wrote:
> This patch add VGA acceleration support for cirrus logic device model.
> It works on 32 guest under 32/64 host env.
Why do you modify xc_vmx_build to unconditionally fill in all 4 entries 
of the PAE PDPT?

  -- Keir


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

Keir Fraser wrote:
> On 23 Sep 2005, at 10:25, Jiang, Yunhong wrote:
> 
>> This patch add VGA acceleration support for cirrus logic device
>> model. It works on 32 guest under 32/64 host env.
> 
> Why do you modify xc_vmx_build to unconditionally fill in all 4
> entries of the PAE PDPT?
> 
>   -- Keir
Currently on xc_vmx_build, the page_array is used as following , assume
the memory is 128M:
the first one used for l3 table.
the second one will be used for l2 table.
the third one and following will be used for l1 table.

When we setup the memory mapping for cirrus logic, it is on high end
memory and will not be on the first l2 table.
At that time, we have two options:
1) Using this patch, setup the l2 table unconditionally on xc_vmx_build.
2) Re-caculating the page array usage, and caculating which page can be
used for the l2 table.

I select the option 1 because, the second method will makes the l2 table
scattered. While with option 1, the page array usage will be clear, at
least will be helpful for debug , for example,  we can caculate the 1:1
page table more easily as following :-)
first one for l3 table
followed 4 (or 1 when 2 level) for l2 table
followed is l1 table.

So how is you opinion? Maybe I should split that part as a seperated
patch, although it is caused by the vga acceleration change.

Thanks
Yunhong Jiang



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

On 23 Sep 2005, at 10:53, Jiang, Yunhong wrote:
> When we setup the memory mapping for cirrus logic, it is on high end
> memory and will not be on the first l2 table.
> At that time, we have two options:
> 1) Using this patch, setup the l2 table unconditionally on 
> xc_vmx_build.
> 2) Re-caculating the page array usage, and caculating which page can be
> used for the l2 table.
[un]setup_mapping does not make assumptions about the location of the 
l2 tables. It reads their addresses from the l3 table. Also, 
setup_mapping already knows how to allocate extra page tables, because 
it allocates extra l1 tables. It can use the same allocation scheme to 
allocate new l2 tables on demand.

Something like this will certainly be needed for 64-bit tables anyway, 
where it''s infeasible to pre-allocate all l3 and l2 table entries.

  -- Keir


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

Keir
	Thanks for your comments very much , please see comments below.

Thanks
Yunhong Jiang

Keir Fraser wrote:
> On 23 Sep 2005, at 10:53, Jiang, Yunhong wrote:
> 
>> When we setup the memory mapping for cirrus logic, it is on high end
>> memory and will not be on the first l2 table.
>> At that time, we have two options:
>> 1) Using this patch, setup the l2 table unconditionally on
>> xc_vmx_build. 2) Re-caculating the page array usage, and caculating
>> which page can be used for the l2 table.
> 
> [un]setup_mapping does not make assumptions about the location of the
> l2 tables. It reads their addresses from the l3 table. Also,
> setup_mapping already knows how to allocate extra page tables, because
> it allocates extra l1 tables. It can use the same allocation scheme to
setup_mapping does not allocate extra l1 table, the extra l1 table is a
parameter for it. The extra table is specially allocated for vga memory
when device model begin running.
Also the [un]setup_mapping read l2 table address from the l3 table
because it is sure the 4  L2 table has been mapped to l3 table on
xc_vmx_build, otherwise it has to do something special to check if the
l2 table is not mapped.
> allocate new l2 tables on demand.
> 
> Something like this will certainly be needed for 64-bit tables anyway,
> where it''s infeasible to pre-allocate all l3 and l2 table entries.
I''m a bit confused on this. This mapping is for 1:1 page table, and
there is only one L3 table and 4 l2 table totally even for 64 bit table.

Thanks
Yunong Jiang
> 
>   -- Keir

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

>> allocate new l2 tables on demand.
>>
>> Something like this will certainly be needed for 64-bit tables anyway,
>> where it''s infeasible to pre-allocate all l3 and l2 table
entries.
>
> I''m a bit confused on this. This mapping is for 1:1 page table,
and
> there is only one L3 table and 4 l2 table totally even for 64 bit 
> table.
Ah yes, good point.

In that case I think the code''s fine as it is. I''ll check it
in.

  -- Keir


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

Keir Fraser wrote:
>>> allocate new l2 tables on demand.
>>> 
>>> Something like this will certainly be needed for 64-bit tables
>>> anyway, where it''s infeasible to pre-allocate all l3 and
l2 table
>>> entries. 
>> 
>> I''m a bit confused on this. This mapping is for 1:1 page
table, and
>> there is only one L3 table and 4 l2 table totally even for 64 bit
>> table.
> 
> Ah yes, good point.
> 
> In that case I think the code''s fine as it is. I''ll check
it in.
> 
>   -- Keir
Hmm, seems you have been persuaded by me, but I can''t persuade myself
after more thinking :-) 

In fact, I''m not quite sure still and hope your feedback.

There may be some problem on current 1:1 page table for 64 bit guest.
Considering a guest has memory more than 4G. Current implementation may
cause problem on physical to machine mapping.

However, this patch works on currently 1:1 page table implementation. So
how about check it in firstly, and I will provide a total solution to
improve the whole thing, because I think the 4 level 1:1 page table is
more complex than 3 level, we may have to provide dynamical setting,
still on consideration.

Thanks
Yunhong Jiang

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

On 23 Sep 2005, at 13:51, Jiang, Yunhong wrote:
> There may be some problem on current 1:1 page table for 64 bit guest.
> Considering a guest has memory more than 4G. Current implementation may
> cause problem on physical to machine mapping.
>
> However, this patch works on currently 1:1 page table implementation. 
> So
> how about check it in firstly, and I will provide a total solution to
> improve the whole thing, because I think the 4 level 1:1 page table is
> more complex than 3 level, we may have to provide dynamical setting,
> still on consideration.
Depends what the 1:1 page table is used for (it''s also supposed to be 
the phys-to-machine table, isn''t it?). If we ignore that latter use (I 
think it can be worked out later) then we are okay so long as the guest 
can never run in 64-bit mode with paging disabled. IIRC that is not a 
valid execution mode?

If it can only run with paging disabled in 16- or 32-bit mode, it can''t
access above 4G pseudophys anyway. :-)

  -- Keir


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

Keir Fraser wrote:
> Depends what the 1:1 page table is used for (it''s also supposed to
be
> the phys-to-machine table, isn''t it?). If we ignore that latter
use (I
> think it can be worked out later) then we are okay so long as the
> guest can never run in 64-bit mode with paging disabled. IIRC that is
> not a valid execution mode?
I think 1:1 page table is used for both paging disabled running AND
physical-to-machine table, so agree that if we ignore the
physical-to-machine table, it is ok with current 1:1 page table
implementaion, but just as you said, we need work out later for
phys-to-machine mapping.

Thanks
Yunhong Jiang
> 
> If it can only run with paging disabled in 16- or 32-bit mode, it
> can''t access above 4G pseudophys anyway. :-)
> 
>   -- Keir

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

On 23 Sep 2005, at 14:46, Jiang, Yunhong wrote:
> I think 1:1 page table is used for both paging disabled running AND
> physical-to-machine table, so agree that if we ignore the
> physical-to-machine table, it is ok with current 1:1 page table
> implementaion, but just as you said, we need work out later for
> phys-to-machine mapping.
Currently that works by mapping the 1:1 top-level page directory as a 
second-level page directory in the monitor pagetables. Obviously that 
doesn''t work if the monitor is using 64-bit pagetables and the 1:1 
tables are in 32-bit pae mode. :-) This cannot be solved by using 
64-bit 1:1 pagetables though (e.g., in that mode we cannot use vm86 
mode).

I think the correct approach will be to create extra page directories 
in the monitor pagetables to map all the 1:1 l1''s, plus extra
l1''s that
map pseudophys memory above 4GB.

In summary, you were correct in the first place. :-)

  -- Keir


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

Keir Fraser wrote:
> On 23 Sep 2005, at 14:46, Jiang, Yunhong wrote:
> 
>> I think 1:1 page table is used for both paging disabled running AND
>> physical-to-machine table, so agree that if we ignore the
>> physical-to-machine table, it is ok with current 1:1 page table
>> implementaion, but just as you said, we need work out later for
>> phys-to-machine mapping.
> 
> Currently that works by mapping the 1:1 top-level page directory as a
> second-level page directory in the monitor pagetables. Obviously that
> doesn''t work if the monitor is using 64-bit pagetables and the 1:1
> tables are in 32-bit pae mode. :-) This cannot be solved by using
> 64-bit 1:1 pagetables though (e.g., in that mode we cannot use vm86
> mode).
> 
> I think the correct approach will be to create extra page directories
> in the monitor pagetables to map all the 1:1 l1''s, plus extra
l1''s
> that map pseudophys memory above 4GB.
> 
> In summary, you were correct in the first place. :-)
> 
>   -- Keir
Thanks for your suggestion very much !
I will work out a fix for it.

Yunhong Jiang

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