Re: remplacing page mappings behind uvm

On Fri, Nov 30, 2007 at 05:59:52PM +0100, Manuel Bouyer wrote:
> Now that I'm thinking about it, it should be possible to create a
> uvm_object backed mapping in the ioctl calls, isn't it ?
> 

I played with this, it seems to work. See the attached privcmd.c
There is a wired entry accounting issue I still need to solve,
which I think is related to MMAPBATCH, but it looks promising.

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

/* $NetBSD: privcmd.c,v 1.21 2007/11/27 11:37:27 pooka Exp $ */

/*-
 * Copyright (c) 2004 Christian Limpach.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software

Re: remplacing page mappings behind uvm

In article <20071201005108.GA17581 <at> antioche.eu.org>,
Manuel Bouyer  <bouyer <at> antioche.eu.org> wrote:
>-=-=-=-=-=-
>
>On Fri, Nov 30, 2007 at 05:59:52PM +0100, Manuel Bouyer wrote:
>> Now that I'm thinking about it, it should be possible to create a
>> uvm_object backed mapping in the ioctl calls, isn't it ?
>> 
>
>I played with this, it seems to work. See the attached privcmd.c
>There is a wired entry accounting issue I still need to solve,
>which I think is related to MMAPBATCH, but it looks promising.
>
- please use the __ versions of the defines: instead of foo use __foo__
- don't use // comments in c.

christos

Re: Location for x86emu

On 30-Nov-2007 Joerg Sonnenberger wrote:
> On a different platform, you would have to map the adapter ROM (needs to
> be done on x86 later as well), figure out the VGA port mapping (to be
> done on x86 as well) and provide real functions for the in/out
> callbacks. I do not know yet, if we need to emulate e.g. the i8254, but
> if we want to use vesafb or so, we certainly have to.

Prep is a very PC-like platform.  Mapping the ROM's is easy enough, as is the
VGA ports, as they are just bog standard PC I/O ports.  We even have an i8254
on the machine.

What exactly are the "in/out callbacks"?  isa_inb/outb?

---
Tim Rightnour <root <at> garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/

Re: remplacing page mappings behind uvm

> > we can easily tweak the api.
> 
> This would mean changing all device's mmap functions, isn't ?

or introduce optional d_foo entry points.
for the purpose of udv_attach, it's a little silly to call a driver for
every single page frames.

as foreign pages can't be represented by paddr_t, some tricks are
necessary for d_mmap+pmap_enter in udv_fault.

> I'd prefer to see support for custom mmap in /kern ...

why?

> Now that I'm thinking about it, it should be possible to create a
> uvm_object backed mapping in the ioctl calls, isn't it ?

you can, but i think it's better to actually implement mmap.

YAMAMOTO Takashi

Re: Location for x86emu

At 05:07 PM 11/30/2007 +0100, Joerg Sonnenberger wrote:
>On Fri, Nov 30, 2007 at 08:54:29AM -0700, Tim Rightnour wrote:
> >
> > On 30-Nov-2007 Joerg Sonnenberger wrote:
> > > src/common could be considered as well, given that it is code that can
> > > be used both in userland and kernel.
> >
> > For me, it would be very useful to have in the prep bootloader.  That being
> > said, I don't know of a particularly good place to put it.
> >
> > How much MD glue code would be required to actually use it?
>
>On x86 I can get away with mapping the BIOS range, the first page and
>another page for stack and data. The default memory functions just
>expect a 1MB VA mapping and read/write to that. I am just passing IO
>requests through.
>
>On a different platform, you would have to map the adapter ROM (needs to
>be done on x86 later as well), figure out the VGA port mapping (to be
>done on x86 as well) and provide real functions for the in/out
>callbacks. I do not know yet, if we need to emulate e.g. the i8254, but
>if we want to use vesafb or so, we certainly have to.

I believe that many ROMs call functions in the base BIOS.  In that 
case, wouldn't you also have to provide a BIOS image for them to call 
into?  In the bad old days, certain things were referenced at hard 
addresses, & I imagine that practice is not totally eliminated.

--Terry 

Re: remplacing page mappings behind uvm

> I played with this, it seems to work. See the attached privcmd.c
> There is a wired entry accounting issue I still need to solve,
> which I think is related to MMAPBATCH, but it looks promising.

i wonder how many objects are used with the usage pattern of xentools.

> 	case IOCTL_PRIVCMD_MMAP:

> 		for (i = 0; i < mcmd->num; i++) {

> 			va = mentry.va & ~PAGE_MASK;
> 			ma = mentry.mfn <<  PGSHIFT; /* XXX ??? */
> 			error  = privcmd_map_obj(vmm, va,
> 			    (mentry.npages << PGSHIFT), &obj);

do you need an object per mentry?

> 			if (error)
> 				return error;
> 
> 			for (j = 0; j < mentry.npages; j++) {
> 				//printf("remap va 0x%lx to 0x%lx\n", va, ma);
> 				maddr[j] = ma;
> 				ma += PAGE_SIZE;
> 			}
> 			simple_lock(&obj->uobj.vmobjlock);
> 			obj->maddr = maddr;
> 			obj->npages = mentry.npages;
> 			obj->domid = mcmd->dom;
> 			simple_unlock(&obj->uobj.vmobjlock);

Re: remplacing page mappings behind uvm

On Sat, Dec 01, 2007 at 04:46:42PM +0900, YAMAMOTO Takashi wrote:
> > > we can easily tweak the api.
> > 
> > This would mean changing all device's mmap functions, isn't ?
> 
> or introduce optional d_foo entry points.
> for the purpose of udv_attach, it's a little silly to call a driver for
> every single page frames.
> 
> as foreign pages can't be represented by paddr_t, some tricks are
> necessary for d_mmap+pmap_enter in udv_fault.

Yes, anyway. And worse, xpq_update_foreign() may fail, and the error has to
be reported back to the caller of IOCTL_PRIVCMD_MMAPBATCH. Without it
qemu-dm doesn't work, I ran into this while getting xentools3-hbm working
on amd64.

> 
> > I'd prefer to see support for custom mmap in /kern ...
> 
> why?

I suspect it would be usefull for some other /kern entries, and
limit the proliferation of /entries in /dev (xsd_kva is an example,
it's natural place would be /kern but needs mmap())

> 
> > Now that I'm thinking about it, it should be possible to create a
> > uvm_object backed mapping in the ioctl calls, isn't it ?
> 

Re: remplacing page mappings behind uvm

On Sat, Dec 01, 2007 at 07:04:59PM +0900, YAMAMOTO Takashi wrote:
> > I played with this, it seems to work. See the attached privcmd.c
> > There is a wired entry accounting issue I still need to solve,
> > which I think is related to MMAPBATCH, but it looks promising.
> 
> i wonder how many objects are used with the usage pattern of xentools.

I'd say a few 10s for qemu-dm. But it's dynamic, they are mmaped and then
unmapped. I'll add a counter to watch it.

> 
> > 	case IOCTL_PRIVCMD_MMAP:
> 
> > 		for (i = 0; i < mcmd->num; i++) {
> 
> > 			va = mentry.va & ~PAGE_MASK;
> > 			ma = mentry.mfn <<  PGSHIFT; /* XXX ??? */
> > 			error  = privcmd_map_obj(vmm, va,
> > 			    (mentry.npages << PGSHIFT), &obj);
> 
> do you need an object per mentry?

I think so, because VA may not be contigous at this point. An optimisation
could be to try to merge contigous VAs in a single object and map entry,
but lets look at it later :)

> 
> > 			if (error)
> > 				return error;
> > 

Re: remplacing page mappings behind uvm

On Sat, Dec 01, 2007 at 02:15:16AM +0000, Christos Zoulas wrote:
> In article <20071201005108.GA17581 <at> antioche.eu.org>,
> Manuel Bouyer  <bouyer <at> antioche.eu.org> wrote:
> >-=-=-=-=-=-
> >
> >On Fri, Nov 30, 2007 at 05:59:52PM +0100, Manuel Bouyer wrote:
> >> Now that I'm thinking about it, it should be possible to create a
> >> uvm_object backed mapping in the ioctl calls, isn't it ?
> >> 
> >
> >I played with this, it seems to work. See the attached privcmd.c
> >There is a wired entry accounting issue I still need to solve,
> >which I think is related to MMAPBATCH, but it looks promising.
> >
> - please use the __ versions of the defines: instead of foo use __foo__

Yes. I commited this. 

> - don't use // comments in c.

Of course. This is was a work in progress, I won't commit it as is :)

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Re: remplacing page mappings behind uvm

i think the easiest fix for the problem which started this thread
is making libxc (back) to use non-anonymous mapping.
as far as you mmap a valid object (either kernfs file or device,
i prefer the latter), uvm_unmap calls pmap_remove for you.

YAMAMOTO Takashi