Xen devel - Apr 2006 - [PATCH 0/6] grantable and address conversion patches

The following patch series are necessary for xen/ia64 VP model.
Although I tested only compiling and booting dom0 on xen/x86_32,
I believe the patches don''t break existing xen/x86.

Xen/IA64 developers have been working on getting vnif, balloon driver
to work. The results of the effort are the series of patches called
the P2M/VP model patches. (They aren''t finished yet though.)
Especially grant table and domain address conversion are the issues.
Some of the common files need to be patched for the issues.

-- 
yamahata

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

On 10 Apr 2006, at 09:32, Isaku Yamahata wrote:
>
> The following patch series are necessary for xen/ia64 VP model.
> Although I tested only compiling and booting dom0 on xen/x86_32,
> I believe the patches don''t break existing xen/x86.
>
> Xen/IA64 developers have been working on getting vnif, balloon driver
> to work. The results of the effort are the series of patches called
> the P2M/VP model patches. (They aren''t finished yet though.)
> Especially grant table and domain address conversion are the issues.
> Some of the common files need to be patched for the issues.
Comments:

1/6: We can''t apply this as it would change the public 3.0 interface 
for x86/64. Do you really need a long? If so, we''ll have to make that 
field arch-dependent in some way.

2/6: This is a poor fix. Either we should make the ring size fixed 
(e.g., 4kB) rather than architectural page-sized, or grants should be 
dynamically allocated in netfront rather than statically allocated. 
This was done quite some time ago for blkfront, and would be the 
preferred (although more difficult) fix here.

3/6: No, let''s just take another bit and stop using PG_arch_1 
altogether. We can thrash out which is the ''best bit'' to take
when the
patches are posted upstream.

4/6: Make the function that fills in map/unmap requests arch-specific? 
At least filling in host_addr should be arch-specific -- we don''t 
really want to overload dev_bus_addr like this.

5/6: This looks acceptable.

6/6: Understood that it''s not for checking in, but it looks kind of 
scary anyhow. :-)

  -- Keir


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

On 10 Apr 2006, at 09:54, Keir Fraser wrote:
> 2/6: This is a poor fix. Either we should make the ring size fixed 
> (e.g., 4kB) rather than architectural page-sized, or grants should be 
> dynamically allocated in netfront rather than statically allocated. 
> This was done quite some time ago for blkfront, and would be the 
> preferred (although more difficult) fix here.
Actually, another option that might be easier that dynamic grant 
allocation, but less restrictive that reducing the size of the rings on 
ia64, would be to modify netfront to queue only up to 256 requests 
simultaneously on any ring, regardless of the actual ring size. Then 
you''d only need to allocate 256 grants per ring, as x86, and the bigger
issue (dynamic allocation of grants) can be fixed later. At that point 
we can lift the restriction of 256 requests per ring without having to 
change the public interface at all (unlike if we''d reduced the 
advertised ring size for ia64).

  -- Keir


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

Thanks for your comments.

On Mon, Apr 10, 2006 at 09:54:20AM +0100, Keir Fraser wrote:
> 1/6: We can''t apply this as it would change the public 3.0
interface
> for x86/64. Do you really need a long? If so, we''ll have to make
that
> field arch-dependent in some way.
Perhaps a long is not needed for several years at least.

> 2/6: This is a poor fix. Either we should make the ring size fixed 
> (e.g., 4kB) rather than architectural page-sized, or grants should be 
> dynamically allocated in netfront rather than statically allocated. 
> This was done quite some time ago for blkfront, and would be the 
> preferred (although more difficult) fix here.
I''ll go this direction.

> 4/6: Make the function that fills in map/unmap requests arch-specific? 
> At least filling in host_addr should be arch-specific -- we don''t 
> really want to overload dev_bus_addr like this.
O.K. I''ll introduce virt_to_host_addr() to xenLinux and make a new
patch.
Is there any explanaition about host_addr and dev_bus_addr?
When I wrote this patch,I guessed that host_addr should have been
arch-indepedent and dev_bus_addr could be arch-depedent.
But it was wrong. I couldn''t find any good explaination/usage samples
of these field.

-- 
yamahata

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

On 10 Apr 2006, at 10:34, Isaku Yamahata wrote:
>> 4/6: Make the function that fills in map/unmap requests arch-specific?
>> At least filling in host_addr should be arch-specific -- we
don''t
>> really want to overload dev_bus_addr like this.
>
> O.K. I''ll introduce virt_to_host_addr() to xenLinux and make a new
> patch.
> Is there any explanaition about host_addr and dev_bus_addr?
> When I wrote this patch,I guessed that host_addr should have been
> arch-indepedent and dev_bus_addr could be arch-depedent.
> But it was wrong. I couldn''t find any good explaination/usage
samples
> of these field.
Yes, the confusion is understandable. :-)  The host_addr indicates 
where in the guest''s address space the mapping should be placed --- on 
x86 this is either a virtual address or the address of a PTE to be 
updated with the mapping, but you can make it what you like and 
pseudo-phys address sounds like a good idea. The name
''host_addr'' is
pretty crappy, I''m not sure why it was chosen.
''guest_addr'' would be
more accurate.

How about defining a function in gnttab.c or gnttab.h to fill in an 
entire map/unmap structure, and make the filling of host_addr dependent 
on XENFEAT_auto_translated_physmap? I think we would do the same thing 
for VP guest on x86 (fill host_addr with pseudo-phys addr rather than 
virtual addr).

  -- Keir


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

I attached the patch which restrict netfront to 256 requests.

On Mon, Apr 10, 2006 at 10:00:38AM +0100, Keir Fraser
wrote:
> 
> On 10 Apr 2006, at 09:54, Keir Fraser wrote:
> 
> >2/6: This is a poor fix. Either we should make the ring size fixed 
> >(e.g., 4kB) rather than architectural page-sized, or grants should be 
> >dynamically allocated in netfront rather than statically allocated. 
> >This was done quite some time ago for blkfront, and would be the 
> >preferred (although more difficult) fix here.
> 
> Actually, another option that might be easier that dynamic grant 
> allocation, but less restrictive that reducing the size of the rings on 
> ia64, would be to modify netfront to queue only up to 256 requests 
> simultaneously on any ring, regardless of the actual ring size. Then 
> you''d only need to allocate 256 grants per ring, as x86, and the
bigger
> issue (dynamic allocation of grants) can be fixed later. At that point 
> we can lift the restriction of 256 requests per ring without having to 
> change the public interface at all (unlike if we''d reduced the 
> advertised ring size for ia64).
> 
>  -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
yamahata


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

On 12 Apr 2006, at 14:22, Isaku Yamahata wrote:
> I attached the patch which restrict netfront to 256 requests.
It''d be good to avoid maintaining the count of available tx grants in 
netfront. Instead you could add a new gnttab interface function 
gnttab_no_grants() to tell you whether your private grant pool is 
exhausted.

I also don''t like the changes to clamp number of grant entries. If the 
maptrack entry size is a limit then let''s fix it. It looks like they 
will have to be 8 bytes rather than 4 bytes, and we can then also get 
rid of the nasty mixing of flags and ref in a single field.

In any case, the gnttab interface changes and netfront changes are 
logically separate patches.

  -- Keir


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

[1/3]
clean up grant_mapping_t.
increase its size from 4bytes to 8bytes and removed tight encoding of
flag and ref.
This change is xen-internal so this shouldn''t affect domain api.

-- 
yamahata


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

[2/3]
instroduce gnttab_empty_grant_references() to check whether grant
references is empty.

-- 
yamahata


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

[3/3]
restrict netfront to 256 grant reference.

-- 
yamahata


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