WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH 2/9] xen: hook io_apic read/write operations

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 2/9] xen: hook io_apic read/write operations
From: venkatesh k <venkatesh7venkatesh@xxxxxxxxx>
Date: Sat, 14 Feb 2009 14:42:59 +0530
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Yinghai Lu <yinghai@xxxxxxxxxx>
Delivery-date: Sat, 14 Feb 2009 01:13:45 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XHExrW1Ja1p9Ce3zMunv0NNJDQA+2er7irHsTB9D6pI=; b=Wojq4N2FOmwccAawYiBVZnzTYr13d76rej2y0Skfway+trOZjKHgalwfV5OLdFqr0T H377v0pylLylJtIDupgUw7v3LVvAW5kGsqz4H50xLFjolNJMpCCR508aX0bd2uGsuzbQ K3CN52HZ88xMJq4iDxoS3sER2K7HGmtHPykvA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AfBUT5OR4q8yr2DKpc+qdlIIe7csT8aXa0MaDkaBBxeDyWRngbTh8YdpcyY9GBigkQ nQ56giky92GGs0uWoGoute0asQw+73NMFPS2PpHLvTdcO0MBDhSa7BwP3qRJtLTnbDDs L8/wKqqNDUw/BD8QSDFGOP/lv5uVaNfWsQYDg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49965768.7040102@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <cover.1234573847.git.jeremy.fitzhardinge@xxxxxxxxxx> <3c7db30686056c9b86cc61ef50dd5572de868512.1234573847.git.jeremy.fitzhardinge@xxxxxxxxxx> <3e46dae897fd5620f50b4cca9272969f5546aa88.1234573847.git.jeremy.fitzhardinge@xxxxxxxxxx> <4996280B.6000104@xxxxxxxxxx> <49965768.7040102@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
i am currently studying in m.a.m college of engg in trichy sir. i have
used in xen 3.3.1  source code using in final year project. The
xen3.3.1 learn in readme file  and make file compiling there are
following errors are identified.
select-repository: Searching `.:..' for linux-2.6.18-xen.hg
select-repository: Ignoring `.'
Unable to determine path to Linux source tree.
Falling back to linux-2.6.18-xen Mercurial repository.
Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg to linux-2.6.18-xen.hg.
/bin/sh: hg: not found
make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 127
make[2]: Leaving directory `/home/mamce/Desktop/Missel/xen-3.3.1'
make[1]: *** [linux-2.6-xen-install] Error 2
make[1]: Leaving directory `/home/mamce/Desktop/Missel/xen-3.3.1'
make: *** [install-kernels] Error 1

On 2/14/09, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> 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@xxxxxxxxxx>
>>> ---
>>>  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
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel