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>, venkatesh k <venkatesh7venkatesh@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 2/9] xen: hook io_apic read/write operations
From: Boris Derzhavets <bderzhavets@xxxxxxxxx>
Date: Sat, 14 Feb 2009 04:42:11 -0800 (PST)
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 04:42:41 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1234615332; bh=cwC4JSx6f/+noi5DBwZiFYN3NJ+0h8YVKnOE12qtfKM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wwefcVQeJYu/ztioqhlk5zDPO8X88/c01YCwlbWpuCrLtRpSkc8AFkVYfpSPIKKPv4XE04yCrr8O5zGVeiNFc4ho3QFfBjl4x7UC+O9MWGvClBpBpUfqaITzlOzkK57p9w04lAIRfm7rkH9SdWazw9KzyWPG59DWDKigrVp0vOM=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M6OwVGFqgtyVwxOChabKWreEHDWnLiAxcFDqT5SNVM7cJWhzjuSdar7gfMXjTP/ls3ev0QClpzK3Vp69NEsPH2ReJ0cG5RLe5DRKdr3GzlpyzzTDbKil4UYcF7SK5vYkw3Bgsix+2SEUBwmwNxhCUbawr0hlPCdZJrW09uH1E0E=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <c4d259900902140112x2521eabn34e4dfd25ac51bb4@xxxxxxxxxxxxxx>
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>
Reply-to: bderzhavets@xxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx


--- On Sat, 2/14/09, venkatesh k <venkatesh7venkatesh@xxxxxxxxx> wrote:
From: venkatesh k <venkatesh7venkatesh@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 2/9] xen: hook io_apic read/write operations
To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
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>
Date: Saturday, February 14, 2009, 4:12 AM

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

***************************
# cd /usr/src/xen-3.3.1
# which hg
***************************



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>