+1... so many great points here that ive thought many times its almost as
if i could have written it
great post!
chris
On Fri, Nov 6, 2015 at 12:22 PM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
&g
been?
I also see both sides but Joanna definitely has some very good points
chris
On Mon, Nov 9, 2015 at 9:46 PM, Radoslaw Szkodzinski
wrote:
> As usual. Security, performance, convenience, price. Pick any mixture.
>
> As is usual for most software, developer convenience trumps m
Add earlycon=xenboot option to Documentation/kernel-parameters.txt.
Signed-off-by: Chris Patterson
---
Documentation/kernel-parameters.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index ecc74fa..e01ec39
On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote:
>> Add earlycon=xenboot option to Documentation/kernel-parameters.txt.
>>
>
> But it is not true.
>
> I tried this on x86: "earlyco
On Tue, Apr 5, 2016 at 12:42 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Apr 05, 2016 at 11:43:36AM -0400, Chris Patterson wrote:
>> On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote:
&g
On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
wrote:
>> - The serial controller on the Tegra SoCs doesn't behave in the same
>> was as most NS16550-compatibles; it actually adheres to the NS16550
>> spec a little more rigidly than most compatible controller
e know how to route. Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this patch set would not support
as-is. I'm not sure of an appropriate way to maintain that logic and
merge them. However, I am certainly open to suggestion, if yo
Will split patches & fix for v2, thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
####
Merged.
--
Chris PeBenito
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
-c
gen_context(system_u:object_r:xen_device_t,s0)
ifdef(`distro_debian',`
# this is a static /dev dir "backup mount"
Merged.
--
Chris PeBenito
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello,
Looking at
https://xenbits.xen.org/xsa/advisory-243.html,
I cannot find the second patch for xen 4.8, xsa243-4.8-2.patch.
The text of the advisory leads me to believe that it should be there, so
it seems to be missing.
-- Chris
___
Xen-devel
On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson wrote:
> On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
>> Hi Chris,
>>
>> On 07/07/17 00:12, Chris Patterson wrote:
>>>>
>>>>
>>>> So why do you want the hardware domain to interact w
,`
# this is a static /dev dir "backup mount"
Merged.
--
Chris PeBenito
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>> The purpose of tegra_interrupt_compat is to maintain a tegra-specific
>> whitelist of interrupt controllers we know how to route. Presumably,
>> there may be custom boards out there that may have additional
>> interrupt routing capabilities that this patch set would not support
>> as-is. I'm n
>
> So why do you want the hardware domain to interact with the ictlr? Could not
> you hide it completely?
>
snip
> What would happen if you enable the interrupt here for the guest? Should not
> you do it when the guest is requesting to enable (see vgic_enable_irqs).
>
>
> Also, how about EOI an
Will fix, thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall wrote:
> Hi Chris,
>
>
> On 06/07/17 23:00, Chris Patterson wrote:
>>>>
>>>> The purpose of tegra_interrupt_compat is to maintain a tegra-specific
>>>> whitelist of interrupt controllers we know how
On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
> Hi Chris,
>
> On 07/07/17 00:12, Chris Patterson wrote:
>>>
>>>
>>> So why do you want the hardware domain to interact with the ictlr? Could
>>> not
>>> you hide it completely?
>
From: "Chris Patterson"
Currently, the interrupt parent is left undefined during creation in
make_gic_node(). In cases where a non-GIC interrupt controller is present,
this can lead to incorrect assignment of interrupt parents.
On the Tegra, the gic's interrupt parent i
From: "Chris Patterson"
The addition of new IRQ-related platform hooks now allow platforms to
perform platform-specific interrupt logic, such as allowing virtualization
of platform-specific interrupt controller hardware.
This commit adds the ability for the platform to identify th
From: "Chris Patterson"
Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be hand
m the original RFC
posted by Kyle Temkin. Kyle has done most of the authoring on this, but I am
picking it up to address the RFC reviews and push it though.
Chris Patterson (6):
xen/arm: platforms: Add earlyprintk and serial support for Tegra
boards.
xen/arm: domain_build: Inherit GIC's
From: "Chris Patterson"
Some common platforms (e.g. Tegra) have non-traditional IRQ controllers
that must be programmed in addition to their primary GICs-- and which
can come in unusual topologies. Device trees for targets that feature
these controllers often deviate from the conven
From: Chris Patterson
Tegra boards feature a NS16550-compatible serial mapped into the MMIO
space. Add support for its use both as a full-featured serial port and
as an earlyprintk driver.
This patch adds a quirk for platforms, such as the Tegra, which require
require the NS16550 Rx timeout
From: Chris Patterson
Several Tegra hardware devices, and the Tegra device tree, expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the hardware domain.
As the Tegra LIC provides t
I have spent some time investigating a case where qemu is failing to
register xenstore watches for a PV guest once I enable vfb (and
thereby triggering the creation of a qemu instance).
The qemu logs show something along the lines of:
xen be core: xen be core: xen be: watching backend path
(backen
From: Chris Patterson
xs_watch() creates a thread to listen to xenstore events. Currently, the
thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
There have been several bug reports and workarounds related to the issue
where xs_watch() fails because its attempt to create the reader
On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu wrote:
> On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
>> > From: Chris Patterson
>> >
>> > xs_watch() creates a thread to l
On Wed, Sep 21, 2016 at 10:07 AM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote:
>> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu wrote:
>> > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
>> >>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>
Sounds good! EST (GMT-5).
Cheers,
-Chris
___
From: Chris Patterson
GCC 6 will warn on unused static const variables in c modules:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html
When compiling with LIBXL_HAVE_NO_SUSPEND_RESUME set (arm & aarch64),
the compiler emits the following errors:
xl_cmdimpl.c:101:19: e
From: Chris Patterson
The uart generates an interrupt whenever the transmit holding register is
empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550
driver does not currently mask this interrupt when transmit is stopped,
unlike other platforms such as Linux [1].
T
On Wed, Aug 17, 2016 at 10:29 AM, Jan Beulich wrote:
>>>> On 17.08.16 at 16:02, wrote:
>> From: Chris Patterson
>>
>> The uart generates an interrupt whenever the transmit holding register is
>> empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen&#x
From: Chris Patterson
The uart generates an interrupt whenever the transmit holding register is
empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550
driver does not currently mask this interrupt when transmit is stopped,
unlike other platforms such as Linux [1].
T
t_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross
> Fixes: 920cf4194954 ("drm/i915: Introduce an internal allo
r, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the intention when that API
> situations.
>
> Signed-off-by: Elena Reshetova
> Signed-off-by: Hans Liljestrand
> Signed-off-by: Kees Cook
> Signed-off-by: David Windsor
This looks OK to me.
Acked-by: Chris Leech
> ---
> drivers/scsi/libiscsi.c| 8
> drivers/scsi/qedi/qedi_is
Hello...
On 11/10/2015 05:52 AM, Lars Kurth wrote:
Hi everyone,
firstly I wanted to thank everyone for raising this issue. I wanted to
point out that we are not talking about a security process here, but
the development process. Or more accurately the cost of writing more
secure code and the
t want to change the page mapping of active scanouts.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address
a compilation error due to the deprecation of readdir_r.
glibc has deprecated this for their next release (2.24):
https://sourceware.org/bugzilla/show_bug.cgi?id=19056
Signed-off-by: Chris Patterson
---
tools
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address
a compilation error due to the deprecation of readdir_r.
glibc has deprecated this for their next release (2.24):
https://sourceware.org/bugzilla/show_bug.cgi?id=19056
This also removes the zalloc_dirent() helper
From: Chris Patterson
In some cross-compilation environments, the CC/CXX variables may
expand out to more than one argument (to include things
like --sysroot=...). Quote these to safely pass along.
Signed-off-by: Chris Patterson
---
xen/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3
On Tue, May 31, 2016 at 6:42 AM, George Dunlap wrote:
> On Mon, May 30, 2016 at 3:32 AM, Chris Patterson wrote:
>> From: Chris Patterson
>>
>> Replace the usage of readdir_r() with readdir() to address
>> a compilation error due to the deprecation of readdir_r.
>
On Tue, May 31, 2016 at 1:53 PM, Wei Liu wrote:
> On Tue, May 31, 2016 at 11:43:13AM -0400, Chris Patterson wrote:
>> On Tue, May 31, 2016 at 6:42 AM, George Dunlap
>> wrote:
>> > On Mon, May 30, 2016 at 3:32 AM, Chris Patterson wrote:
>> >> From: Chris Patt
And
>> only contrived implementations of readdir will not be threadsafe in
>> the required sense.
> ...
>> Accordingly, I think all occurrences of readdir_r in our codebase
>> should be replaced by readdir, as proposed by Chris.
>>
>> However, I think the patch is no
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address a
compilation error under glibc due to the deprecation of readdir_r
for their next release (2.24) [1, 2].
Remove code specific to usage of readdir_r which is no longer required,
such as zalloc_dirent().
--
From
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address a
compilation error under glibc due to the deprecation of readdir_r
for their next release (2.24) [1, 2].
--
From the GNU libc manual [3]:
"
It is expected that future versions of POSIX will obsolete read
On Thu, Jun 2, 2016 at 6:11 AM, Ian Jackson wrote:
> Chris Patterson writes ("[[PATCH v2 2/2] libxl: replace deprecated
> readdir_r() with readdir()"):
>> -for (;;) {
>> +while ((de = readdir(dir)) != NULL) {
> ...
>> -int r = readdir_r
On Thu, Jun 2, 2016 at 12:13 PM, Ian Jackson wrote:
> Chris Patterson writes ("Re: [[PATCH v2 2/2] libxl: replace deprecated
> readdir_r() with readdir()"):
>> You're right, it should check for the error afterwards.
>>
>> How about something along the
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address a
compilation error under glibc due to the deprecation of readdir_r
for their next release (2.24) [1, 2].
Add new error checking on readdir(), and fail if error occurs.
--
From the GNU libc manual [3]:
"
From: Chris Patterson
Replace the usage of readdir_r() with readdir() to address a
compilation error under glibc due to the deprecation of readdir_r
for their next release (2.24) [1, 2].
Remove code specific to usage of readdir_r which is no longer required,
such as zalloc_dirent().
--
From
Hey can someone add AMD Radeon R9 390 to the Tested Adapters list here
http://wiki.xenproject.org/wiki/Xen_VGA_Passthrough_Tested_Adapters
I've requested edit access, but don't yet have it.
Thank
And thanks Ian for your vision and dogged persistence on this. Great to have
this up and running!
-Original Message-
From: wg-test-framework-boun...@lists.xenproject.org
[mailto:wg-test-framework-boun...@lists.xenproject.org] On Behalf Of Ian Jackson
Sent: 26 March 2015 13:25
To: wg-tes
s the assignments to match the declaration, making it
clearer which ones are missing. Patch 2 then adds the missing bits.
Chris
Chris Brand (2):
xen: arm re-order assignments in mfn_to_xen_entry()
xen: arm: Be explicit about bit values in mfn_to_xen_entry()
xen/include/asm-arm/page.h
Ensure that every relevant bit is given an explicit value.
This has no effect on the generated code, but makes it
a little easier to follow.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
v3 trims down the list of bits given explicit values
v2 adds comments on pxn and avail
xen
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand
Reviewed-by: Julien
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand
Reviewed-by: Julien
s the assignments to match the declaration, making it
clearer which ones are missing. Patch 2 then adds the missing bits.
Chris
Chris Brand (2):
xen: arm re-order assignments in mfn_to_xen_entry()
xen: arm: Set all bits in mfn_to_xen_entry()
xen/include/asm-arm/page.h | 19 ---
1
Ensure that every bit has a specific value.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
v2 adds comments on pxn and avail.
xen/include/asm-arm/page.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index
etting the "contig" bit in the PTEs.
Signed-off-by: Chris Brand
---
Changed in v2: merged create_32mb_mappings() and create_2mb_mappings()
into create_mappings(). A side-effect is to fix the bug in v1 for
ARM64 systems with <4GB RAM.
Changed in v3: Ensure that the granularity variabl
platform-specific Xen code - it looks like all the code there related to
bringing up secondary cores runs on the primary.
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
ot understanding what's happening in my system rather
than anything wrong with the patch.
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
roperty. So your patch isn't designed to help in this case
(CNTFRQ set on core 0 only, no clock-frequency property in timer node of DT).
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
#x27;t yet do it, I would try to clean Xen repository and try to
>rebuild Xen to see if the build system was using a stall DTB by mistake.
I have, but I'll do it again.
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
-frequency file.
When I then fire up DomU and do the same command, it too has a clock-frequency
node.
Thanks,
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>Can I get your Tested-by on this patch?
Tested-by: Chris Brand
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
e start of the array definitely seems like a bug that should be fixed
(although in practice those values are never used for node 0). Looking through
the history, it seems to have been like that since the function was first
introduced
(http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9cf4a9a467171c8a2c3d97c2bfadb1bc8b15a3d6).
I'm happy to test out any patches.
Chris
(Not subscribed to the list)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
er is
"yes". I have this log from an earlier run where I ran Linux without Xen. I
*believe* used that same DT:
[0.00] Memory: 208924K/3145728K available (5557K kernel code, 280K
rwdata, 1740K rodata, 3892K init, 213K bss, 36836K reserved
etting the "contig" bit in the PTEs.
Signed-off-by: Chris Brand
---
xen/arch/arm/mm.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a91ea774f1f9..47b6d5d44563 100644
--- a/xen/arc
64.
>
> It might be good to support 2MB for ARM64 too.
Whoops! Yes, I've messed the ARM64 path up at some point while cleaning
up the code. Will fix.
Thanks,
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
nly executed if you specify a previously-invalid value for xenheap_megabytes
> on the
> command-line, so it won't affect any existing systems.
This sentence is a lie, sorry. Please ignore it. :-)
> Is it worth adding a sentence
> mentioning performan
etting the "contig" bit in the PTEs.
Signed-off-by: Chris Brand
---
Changed in v2: merged create_32mb_mappings() and create_2mb_mappings()
into create_mappings(). A side-effect is to fix the bug in v1 for
ARM64 systems with <4GB RAM.
xen/arch/arm/mm.c | 37 ++
Any thoughts on v2 ?
Chris
> -Original Message-
> From: Chris (Christopher) Brand
> Sent: Friday, 07 August, 2015 1:41 PM
> To: 'Julien Grall'; xen-devel@lists.xen.org
> Cc: Stefano Stabellini; Ian Campbell (ian.campb...@citrix.com)
> Subject: [PATCH
et the contig bit to 0 (or anything else). So the
> value will be undefined for MB(2) mapping.
>
> It looks like to me that mfn_to_xen_entry should always set the contig bit to
> 0. I'm not sure why we didn't see any issue until now. Can you please send a
> patch fo
s the assignments to match the declaration, making it clearer
which ones are missing. Patch 2 then adds the missing bits.
Chris
P.S. Apologies for any threading issues - I have not yet managed to get git
send-email working properly.
___
Xen-devel mailing
s the assignments to match the declaration, making it clearer
which ones are missing. Patch 2 then adds the missing bits.
Chris
P.S. Apologies for any threading issues - I have not yet managed to get git
send-email working properly.
___
Xen-devel mailing
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand
---
xen/include
Ensure that every bit has a specific value.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
xen/include/asm-arm/page.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 01628f3e96cb..7a56b2cb463a 100644
--- a/xen
ng table to 0, these are ignored, and any code
setting
table to 1 should then set them. I can obviously easily set them here (I guess
all
to zero would make sense) if you think it's worthwhile ...
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
l *.patch which will send the patch correctly
> threading.
Yeah, the difficulty is finding the right set of --smtp* options to get it
through our corporate mail server. I had it working once upon a time
when I was working for Linaro, but something somewhere
Hi Andrew,
> On 21/08/15 00:33, Chris Brand wrote:
> > Ensure that every bit has a specific value.
> >
> > Reported-by: Julien Grall
> > Signed-off-by: Chris Brand
> > ---
> > v2 adds comments on pxn and avail.
>
> This is no functional change
but I believe the answer is
>"yes".
But in fact the answer is indeed "no". The log that I found was from a
different device tree.
I still think the code shouldn't be reading before the start of the two arrays,
but it does function correctly.
Chris
_
y is full, using the latter will in
fact access beyond the end of the array.
This was done correctly in boot_module_find_by_kind() and
consider_modules() but incorrectly in discard_initial_modules()
and next_module().
Signed-off-by: Chris Brand
---
xen/arch/arm/setup.c | 4 ++--
1 file changed, 2 insert
y is full, using the latter will in
fact access beyond the end of the array.
This was done correctly in boot_module_find_by_kind() and
consider_modules() but incorrectly in discard_initial_modules()
and next_module().
Signed-off-by: Chris Brand
---
xen/arch/arm/setup.c | 4 ++--
1 file changed
pdxs * sizeof(struct page_info);
[...]
/* Round up to 32M boundary */
frametable_size = (frametable_size + 0x1ff) & ~0x1ff;
Thanks,
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> It looks like the mail as been sent in HTML. Can you resend it in plain text?
Re-sent, hopefully correctly this time.
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
is right in the
middle, and the functions are pretty short).
Chris
From: Chris Brand
Date: Mon, 20 Jul 2015 13:38:15 -0700
Subject: [PATCH] xen: arm: Support <32MB frametables
setup_frametable_mappings() rounds frametable_size up to a multiple
of 32MB. This is wasteful on systemes with l
32 will cause Xen to hit this assert and fail to boot.
Signed-off-by: Chris Brand
---
docs/misc/xen-command-line.markdown | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 4889e27626d4..f3d3bd6ce56a
s.
Typo : "gfn"
I'd suggest "...replace any reference to mfn with gfn..."
[...]
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
89 matches
Mail list logo
