[RFC PATCH 4/5] lguest: ignore bad virtqueues.

Currently the lguest Launcher aborts when a Guest puts something bogus in a virtio queue. If we want to deal with other (untrusted) Guests' queues, that's a bad idea: simply print a warning and ignore it from now on. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- Documentation/lguest/lgues

[RFC PATCH 5/5] lguest: Inter-guest networking

We open two FIFOs, mmap the other Guests' memory, and copy between their send queue and our Guest's receive queue. A one-char byte is used to notify the other Guest about virtqueue activity. Note the FIXMEs, and the fact that we don't suppress notifications even when we could (based on the flags

[RFC PATCH 3/5] lguest: separate out virtqueue info from device info.

To deal with other Guest's virtqueue, we need to separate out the parts of the structure which deal with the actual virtqueue from configuration information and the device. Then we can change the virtqueue descriptor handling functions to take that smaller structure. Signed-off-by: Rusty Russell

[RFC PATCH 2/5] lguest: Encapsulate Guest memory ready for dealing with other Guests.

We currently keep Guest memory pointer and size in globals. We move this into a structure and explicitly hand that to to_guest_phys() and from_guest_phys() so we can deal with other Guests' memory. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- Documentation/lguest/lguest.c | 89

[RFC PATCH 1/5] lguest: mmap backing file

From: Paul TBBle Hampson <[EMAIL PROTECTED]> This creates a file in $HOME/.lguest/ to directly back the RAM and DMA memory mappings created by map_zeroed_pages. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- Documentation/lguest/lguest.c | 59 -- 1

[RFC PATCH 0/4] Inter-guest virtio I/O example with lguest

Hi all, Just finished my prototype of inter-guest virtio, using networking as an example. Each guest mmaps the other's address space and uses a FIFO for notifications. There are two issues with this approach. The first is that neither guest can change its mappings. See patch 1. The s

Re: [PATCH] virtio_pci: unregister virtio device at device remove

On Thursday 20 March 2008 12:35:04 Anthony Liguori wrote: > Make sure to call unregister_virtio_device() when a virtio device is > removed. Otherwise, virtio_pci.ko cannot be rmmod'd. > > This was spotted by Marcelo Tosatti. > > Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]> Thanks, applied.

[PATCH] virtio_pci: unregister virtio device at device remove

Make sure to call unregister_virtio_device() when a virtio device is removed. Otherwise, virtio_pci.ko cannot be rmmod'd. This was spotted by Marcelo Tosatti. Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 59a8f73..

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

On Thu, Mar 20, 2008 at 6:39 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Well all we have in the changelog is > > Implement support for the E-Ink Metronome controller. It provides an > mmapable interface to the controller using defio support. It was tested > with a gumstix pxa255 with

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

On Thu, 20 Mar 2008 06:30:37 +0800 "Jaya Kumar" <[EMAIL PROTECTED]> wrote: > On Thu, Mar 20, 2008 at 2:37 AM, Andrew Morton > <[EMAIL PROTECTED]> wrote: > > > > Do we need some of all of that patch in 2.6.25? I wasn't aware of such a > > need. > > > > If the drivers/video/fb_defio.c hunk of th

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

On Thu, Mar 20, 2008 at 2:37 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Do we need some of all of that patch in 2.6.25? I wasn't aware of such a > need. > > If the drivers/video/fb_defio.c hunk of that patch fixes something then I'd > be inclined to merge the whole thing - adding a new d

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

On Wed, 19 Mar 2008 19:24:25 +0800 "Jaya Kumar" <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 6:45 PM, Markus Armbruster <[EMAIL PROTECTED]> wrote: > > > > Any progress on this? > > > > Considering that fb_defio is utterly broken without the fix (writing > > the frame buffer makes the VM

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

On Wed, Mar 19, 2008 at 6:45 PM, Markus Armbruster <[EMAIL PROTECTED]> wrote: > > Any progress on this? > > Considering that fb_defio is utterly broken without the fix (writing > the frame buffer makes the VM endlessly invoke vm_ops.page_mkwrite()), > wouldn't it make sense to merge the fix eve

Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized

"Jaya Kumar" <[EMAIL PROTECTED]> writes: > On Tue, Feb 26, 2008 at 9:45 AM, Markus Armbruster <[EMAIL PROTECTED]> wrote: >> >> What about pushing the fb_defio fixes independently of any new >> fb_defio users? If fb_defio was worth merging into Linus's tree, it >> should be worth fixing there,