From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 2/9] xen: hook io_apic read/write operations
Date: Fri, 13 Feb 2009 21:32:24 -0800 [thread overview]
Message-ID: <49965768.7040102@goop.org> (raw)
In-Reply-To: <4996280B.6000104@kernel.org>
Yinghai Lu wrote:
> Jeremy Fitzhardinge wrote:
>
>> In Xen, writes to the IO APIC are paravirtualized via hypercalls, so
>> implement the appropriate operations.
>>
>> This version of the patch just hooks the io_apic read/write functions
>> directly, rather than introducing another layer of indirection. The
>> xen_initial_domain() tests compile to 0 if CONFIG_XEN_DOM0 isn't set,
>> and are cheap if it is.
>>
>> (An alternative would be to add io_apic_ops, and point them to the Xen
>> implementation as needed. HPA deemed this extra level of indirection to
>> be excessive.)
>>
>
> that will be more clean.
>
That was my thought too.
>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>> ---
>> arch/x86/include/asm/io_apic.h | 6 ++++
>> arch/x86/kernel/io_apic.c | 32 ++++++++++++++++++++--
>> arch/x86/xen/Makefile | 3 +-
>> arch/x86/xen/apic.c | 57 ++++++++++++++++++++++++++++++++++++++++
>> arch/x86/xen/enlighten.c | 2 +
>> arch/x86/xen/xen-ops.h | 6 ++++
>> 6 files changed, 102 insertions(+), 4 deletions(-)
>> create mode 100644 arch/x86/xen/apic.c
>>
>> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
>> index 59cb4a1..20b543a 100644
>> --- a/arch/x86/include/asm/io_apic.h
>> +++ b/arch/x86/include/asm/io_apic.h
>> @@ -183,4 +183,10 @@ static inline void ioapic_init_mappings(void) { }
>> static inline void probe_nr_irqs_gsi(void) { }
>> #endif
>>
>> +void xen_io_apic_init(void);
>> +unsigned int xen_io_apic_read(unsigned apic, unsigned reg);
>> +void xen_io_apic_write(unsigned int apic,
>> + unsigned int reg, unsigned int value);
>> +
>> +
>> #endif /* _ASM_X86_IO_APIC_H */
>> diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
>> index 7248ca1..de0368a 100644
>> --- a/arch/x86/kernel/io_apic.c
>> +++ b/arch/x86/kernel/io_apic.c
>> @@ -62,6 +62,8 @@
>> #include <asm/uv/uv_hub.h>
>> #include <asm/uv/uv_irq.h>
>>
>> +#include <asm/xen/hypervisor.h>
>> +
>> #include <asm/genapic.h>
>>
>> #define __apicdebuginit(type) static type __init
>> @@ -399,14 +401,26 @@ static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
>>
>> static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
>> {
>> - struct io_apic __iomem *io_apic = io_apic_base(apic);
>> + struct io_apic __iomem *io_apic;
>> +
>> + if (xen_initial_domain())
>> + return xen_io_apic_read(apic, reg);
>>
>
> you may have _xen_io_apic_read(apic, reg);
> and xen_io_apic_read(apic, reg) will call xen_initial_domain internally.
>
How would that work? What would it return in the xen/non-xen states to
indicate that the normal read operation should be performed? I don't
think it would be any clearer.
> or sth like
> extra if (io_apic_ops)
> io_apic->read()...
>
I think if there were an _ops structure, it should just go though it
unconditionally.
J
next prev parent reply other threads:[~2009-02-14 5:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-14 1:11 [PATCH 0/9] *** SUBJECT HERE *** Jeremy Fitzhardinge
2009-02-14 1:11 ` [PATCH 1/9] xen/dom0: handle acpi lapic parsing in Xen dom0 Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 2/9] xen: hook io_apic read/write operations Jeremy Fitzhardinge
2009-02-14 2:10 ` Yinghai Lu
2009-02-14 5:32 ` Jeremy Fitzhardinge [this message]
2009-02-14 9:12 ` [Xen-devel] " venkatesh k
2009-02-14 1:12 ` [PATCH 3/9] xen: create dummy ioapic mapping Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 4/9] xen: implement pirq type event channels Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 5/9] x86/io_apic: add get_nr_irqs_gsi() Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 6/9] xen/apic: identity map gsi->irqs Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 7/9] xen: direct irq registration to pirq event channels Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 8/9] xen: bind pirq to vector and event channel Jeremy Fitzhardinge
2009-02-14 1:12 ` [PATCH 9/9] xen: pre-initialize legacy irqs early Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49965768.7040102@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Campbell@citrix.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.