On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> ea.
>
> I don't see why you're bending over so far backwards to accommodate
> this GRU thing that we don't even have numbers for and could actually
> potentially be batched up in other ways (eg. using mmu_gather or
> mmu_gather-like idea).
On Thu, 2008-05-08 at 00:44 +0200, Andrea Arcangeli wrote:
>
> Please note, we can't allow a thread to be in the middle of
> zap_page_range while mmu_notifier_register runs.
You said yourself that mmu_notifier_register can be as slow as you
want ... what about you use stop_machine for it ? I'm n
On Tue, 2008-04-01 at 16:18 -0500, Hollis Blanchard wrote:
> The point is that a virtio device appears as a PCI device. Like all
> other PCI devices, it has config space. Unlike all other PCI devices,
> its config space is accessed with 1-byte reads.
Which is weirdo ... it you guys make it look l
> > Config space should be 8/16/32. Is that ever bridged to real PCI config
> > space anyway ? Or only virtio ? And it should be endian swapped at the
> > low level, either by your HV calls or by the low level kernel. Always.
> > That's how PCI config space is supposed to work.
> >
>
> I guess
On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote:
> It's the unfortunate side-effect of using PCI config space without
> passing it's semantics through to the virtio devices. Right now, you do
> a config_get which is basically a memcpy. If we didn't do accesses with
> ioread8(), you
On Fri, 2008-01-25 at 12:42 +0100, Andrea Arcangeli wrote:
> On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
> > Andrea's mmu_notifier #4 -> RFC V1
> >
> > - Merge subsystem rmap based with Linux rmap based approach
> > - Move Linux rmap based notifiers out of macro
> > - Try t
On Wed, 2008-01-23 at 16:17 +0200, Avi Kivity wrote:
> Robin Holt wrote:
> > On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
> >
> >> Jumping in here, looks like this could develop into a direction useful
> >> for Xen.
> >>
> >> Background: Xen has a mechanism called "grant tabl
On Tue, 2008-01-22 at 12:34 -0800, Christoph Lameter wrote:
>
> - Notifiers are called *after* we tore down ptes. At that point pages
> may already have been freed and reused. This means that there can
> still be uses of the page by the user of mmu_ops after the OS has
> dropped its mapping
On Tue, 2008-01-15 at 13:44 +0100, Andrea Arcangeli wrote:
> On Mon, Jan 14, 2008 at 12:02:42PM -0800, Christoph Lameter wrote:
> > Hmmm... In most of the callsites we hold a writelock on mmap_sem right?
>
> Not in all, like Marcelo pointed out in kvm-devel, so the lowlevel
> locking can't relay
On Mon, 2008-01-14 at 12:02 -0800, Christoph Lameter wrote:
> On Sun, 13 Jan 2008, Andrea Arcangeli wrote:
>
> > About the locking perhaps I'm underestimating it, but by following the
> > TLB flushing analogy, by simply clearing the shadow ptes (with kvm
> > mmu_lock spinlock to avoid racing with
On Sun, 2008-01-13 at 17:24 +0100, Andrea Arcangeli wrote:
> Hello,
>
> This patch is last version of a basic implementation of the mmu
> notifiers.
>
> In short when the linux VM decides to free a page, it will unmap it
> from the linux pagetables. However when a page is mapped not just by
> th
> The X fbdev driver is going to make supporting a new fb ioctl pretty
> fun. It currently doesn't even support the existing fb ioctls and has a
> strange abstraction layer.
>
> I reckon writing a new X driver from scratch (or based on something like
> the vnc X driver) would be easier in the
On Tue, 2007-06-12 at 09:19 +1000, Rusty Russell wrote:
> > Rectangles work just fine for a framebuffer console. They stop
> working
> > once you plan to run any graphical stuff such as an X-Server on top
> of
> > the framebuffer. Only way to get notified about changes is page
> faults,
> > i.
13 matches
Mail list logo
