[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0906021751510.3419@localhost.localdomain>
Date: Tue, 2 Jun 2009 18:11:04 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Jeremy Fitzhardinge <jeremy@...p.org>
cc: Ingo Molnar <mingo@...e.hu>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Xen-devel <xen-devel@...ts.xensource.com>,
Christophe Saout <chtephan@...o.intern.saout.de>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 14/16] paravirtualize IO permission bitmap
On Tue, 12 May 2009, Jeremy Fitzhardinge wrote:
> From: Christophe Saout <chtephan@...o.intern.saout.de>
>
> A PV Xen guest kernel has no TSS of its own, so the IO permission
> bitmap must be paravirtualized. This patch adds set_io_bitmap
> as a paravirt op, and defines a native version which updates the tss,
> and a Xen version which uses a hypercall.
>
> This is much easier now that 32 and 64-bit use the same code to
> manage the IO bitmap.
Sigh, is there a plan to limit the paravirt horror at some point or
are we keeping on adding to it forever ?
> --- a/arch/x86/kernel/ioport.c
> +++ b/arch/x86/kernel/ioport.c
> @@ -30,14 +30,31 @@ static void set_bitmap(unsigned long *bitmap, unsigned int base,
> }
> }
This needs kernel doc annotation and a comment about the calling
conventions i.e. preemption disabled.
> +void native_set_io_bitmap(struct thread_struct *t,
> + int changed, unsigned long bytes_updated)
> +{
> + struct tss_struct *tss;
> +
> + if (!bytes_updated)
> + return;
> +
> + tss = &__get_cpu_var(init_tss);
> +
> + /* Update the TSS: */
> + if (t->io_bitmap_ptr)
> + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated);
> + else
> + memset(tss->io_bitmap, 0xff, bytes_updated);
> +}
> +
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists