>>> On 24.02.15 at 19:29, wrote:
> +/*
> + * Test out special #GP handling for the VMware port 0x5658.
> + * This is done in two "modes", j=0 and j=1. Testing 4
> + * instructions (all the basic PIO) in both modes.
> + *
> + * The port used is based on j.
> + *
> +
>>> On 24.02.15 at 18:14, wrote:
> Since this is not an architecture feature and I do not expect any real
> CPUs to support this, I do not expect any other use. But I am happy
> to make it more generic.
Let's see how this ends up looking - the hook is probably indeed
bogus (from an architectural
On Tue, 2015-02-24 at 21:42 -0500, Meng Xu wrote:
> Hi all,
>
Hello,
> 2015-02-24 11:35 GMT-05:00 Dario Faggioli :
> > On Tue, 2015-02-24 at 14:16 +, Ian Campbell wrote:
> >> On Tue, 2015-02-24 at 11:30 +, Dario Faggioli wrote:
> >
> >> > Semantically speaking, they just should be killed.
>>> On 24.02.15 at 19:00, wrote:
> Paul Durrant writes ("RE: [qemu-upstream-unstable bisection] complete
> test-amd64-i386-freebsd10-i386"):
>> I thought this was fixed. I posted the fix over a week ago and it's applied:
>
> Looking at the most recent tests it appears that there is a
> combinati
On Tue, 2015-02-24 at 13:10 +, Ian Campbell wrote:
> On Tue, 2015-02-24 at 12:41 +, Anthony PERARD wrote:
> > What libxl API those provide this information, if it exist?
> >
> > I found libxl_get_online_cpus() but that not enough. They want a
> > bitmap.
>
> I think that is all which cur
>>> On 24.02.15 at 20:11, wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -27,35 +27,79 @@ static nodemask_t memory_nodes_parsed __initdata;
> static nodemask_t processor_nodes_parsed __initdata;
> static nodemask_t nodes_found __initdata;
> static struct node nodes[MAX_NUMN
On 24/02/15 16:41, Ian Campbell wrote:
Are/were you aware ofhttps://pypi.python.org/pypi/pyxs which sounds
like something similar, judging from its blurb alone?
No, I wasn't. It certainly looks a more solid implementation than mine.
https://launchpad.net/pyxenstore/ might be too, although I
On Wed, 2015-02-25 at 10:24 +0100, Dario Faggioli wrote:
> On Tue, 2015-02-24 at 13:10 +, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 12:41 +, Anthony PERARD wrote:
>
> > > What libxl API those provide this information, if it exist?
> > >
> > > I found libxl_get_online_cpus() but that n
>>> On 24.02.15 at 20:11, wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -843,7 +843,8 @@ void __cpu_die(unsigned int cpu)
>
> int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t pxm)
> {
> -int node, cpu = -1;
> +nodeid_t node;
Please take the opportun
>>> On 24.02.15 at 20:11, wrote:
> Instead of using a hardcoded constant to extract nodeID from
> memflags use a macro whose value is based on nodeid_t size.
>
> Also provide a macro for extracting nodeID from memflags so that
> users don't need to remember to decrement the value.
>
> Signed-off
On Tue, 2015-02-24 at 20:39 +0100, Samuel Thibault wrote:
> Ack-by: Samuel Thibault
Thanks.
Can I take it you are OK in principal with the plans to move things out?
TBH I think it'll make very little difference to your day-to-day
maintenance.
___
Xe
Ian Campbell, le Wed 25 Feb 2015 09:53:52 +, a écrit :
> On Tue, 2015-02-24 at 20:39 +0100, Samuel Thibault wrote:
> > Ack-by: Samuel Thibault
>
> Can I take it you are OK in principal with the plans to move things out?
Yes.
> TBH I think it'll make very little difference to your day-to-day
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 24 February 2015 18:00
> To: Paul Durrant
> Cc: Stefano Stabellini; xen-de...@lists.xensource.com; Ian Campbell
> Subject: RE: [qemu-upstream-unstable bisection] complete test-amd64-i386-
> freebsd10-i386
>
* Greg KH wrote:
> > >It's:
> > >
> > > d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
> >
> > Yes, This is the original patch. Please note I have taken out the
> > READ_ONCE changes from the original patch to avoid build warnings
> > mentioned below.
> > (Those READ_ONCE
Am 25.02.2015 um 11:08 schrieb Ingo Molnar:
>
> * Greg KH wrote:
>
It's:
d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
>>>
>>> Yes, This is the original patch. Please note I have taken out the
>>> READ_ONCE changes from the original patch to avoid build war
On Wed, 2015-02-25 at 09:39 +, Simon Rowe wrote:
> On 24/02/15 16:41, Ian Campbell wrote:
> > Are/were you aware ofhttps://pypi.python.org/pypi/pyxs which sounds
> > like something similar, judging from its blurb alone?
>
> No, I wasn't. It certainly looks a more solid implementation than min
On 24 February 2015 at 19:14, Laszlo Ersek wrote:
> On 02/24/15 20:01, Ard Biesheuvel wrote:
>> On 24 February 2015 at 18:41, Laszlo Ersek wrote:
>>> On 02/24/15 19:37, Ard Biesheuvel wrote:
On 24 February 2015 at 18:34, Laszlo Ersek wrote:
> On 02/24/15 19:02, Ard Biesheuvel wrote:
>>>
On Mon, Feb 23, 2015 at 04:24:32PM +, Ian Campbell wrote:
> On Fri, 2015-02-13 at 13:09 +, Wei Liu wrote:
> > On Mon, Feb 02, 2015 at 04:06:09PM +0800, Chao Peng wrote:
> > > +#ifdef LIBXL_HAVE_PSR_MBM
> > > +int libxl_psr_cmt_type_supported(libxl_ctx *ctx, libxl_psr_cmt_type
> > > type);
On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
> On 24/02/15 7:13 pm, Julien Grall wrote:
> > On 24/02/15 00:23, Manish Jaggi wrote:
> >>> Because you have to parse all the device tree to remove the reference
> >>> to the second ITS. It's pointless and can be difficult to do it.
> >>>
> >>
* Christian Borntraeger wrote:
> > By all means!
> >
> > You'll first need to cherry-pick these commits:
>
> > 927609d622a3 kernel: tighten rules for ACCESS ONCE
> > c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
> > dd36929720f4 kernel: make READ_ONCE() valid on const arguments
>
On Wed, 2015-02-25 at 18:21 +0800, Chao Peng wrote:
> On Mon, Feb 23, 2015 at 04:24:32PM +, Ian Campbell wrote:
> > On Fri, 2015-02-13 at 13:09 +, Wei Liu wrote:
> > > On Mon, Feb 02, 2015 at 04:06:09PM +0800, Chao Peng wrote:
> > > > +#ifdef LIBXL_HAVE_PSR_MBM
> > > > +int libxl_psr_cmt_t
>>> On 24.02.15 at 20:11, wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -27,35 +27,79 @@ static nodemask_t memory_nodes_parsed __initdata;
> static nodemask_t processor_nodes_parsed __initdata;
> static nodemask_t nodes_found __initdata;
> static struct node nodes[MAX_NUMN
>>> On 24.02.15 at 20:11, wrote:
> @@ -121,10 +123,12 @@ struct npfec {
> #define _MEMF_exact_node 4
> #define MEMF_exact_node (1U<<_MEMF_exact_node)
> #define _MEMF_node8
> -#define MEMF_node(n) n)+1)&0xff)<<_MEMF_node)
> +#define MEMF_node(n) n)+1) & MEMF_node_mas
flight 35070 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 34227
test-amd64-amd64-xl-w
Translated address (in d->arch.vgic.{c,d}base) are now bus addresses
which could not always be applied to the DT.
Copy the original address from DT directly to get the original
untraslated reg property which will give same d->arch.vgic.{c,d}base
values once translated again.
Signed-off-by: Fredian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-1563 / XSA-118
version 2
arm: vgic: incorrect rate limiting of guest triggered logging
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
==
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Acked-by: Ian Campbell
[ output trimmed ]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Factor out per-subsystem build/clean/distclean-% targets, so that we can
build subsystems independently in top level directory.
The motive behind this is after splitting out mini-os from Xen tree,
stubdom is in effect a downstream of mini-os. I would like to have the
ability to build it independe
All objects are placed inside stubdom's directories, so there is no need
to enter mini-os and clean.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Samuel Thibault
Cc: Stefano Stabellini
---
stubdom/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/stubdom/Makefile b/s
Don't look for mini-os source file during configure. Mini-os source code
will be fetched during build.
Instead look for xenstore-minios.cfg.
Please rerun autogen.sh after applying this patch.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Acked-by: Ian Campbell
---
Changes in v2:
1.
In order to keep the tree bisectable all the changes are done in one
single commit.
Things done in this commit:
1. Import necessary .mk files from Xen.
2. Move all XEN_ related variables to MINIOS_ namespace.
3. Import Xen public header files.
4. Import BSD's list.h and helper script.
Mini-OS's
This is v3 of my mini-os splitting off patch series.
I use following runes to split off mini-os:
git filter-branch --tag-name-filter cat \
--subdirectory-filter extras/mini-os/ -- --all
# There is already a tag name 4.3.0-rc2 which points to the same commit.
git tag -d xen-4.3.0-rc2
Otherwise mkdir extras/mini-os fails because extras doesn't exist.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Acked-by: Ian Campbell
---
scripts/git-checkout.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
i
Cross compiling libxc requires some symlinks to exist.
Note that make -C tools/include requires running tools/configure. But at
least now the error message is much better than just a "file not found"
error.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jakcson
Acked-by: Ian Campbell
Acked-b
Provide mini-os url and revision in Config.mk
Make stubdom targets depend on mini-os-dir target. Make
subtree-force-update{,-all} depend on mini-os-dir-force-update.
Also make mktarball script generate mini-os archive.
Original mini-os directory is renamed to mini-os-intree to help reduce
patch
flight 35349 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
On Tue, 24 Feb 2015, Ian Campbell wrote:
> On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > Now that we autodetect the use of dom0_mem and set autoballooning
> > > correctly perhaps we should just revert a39b5bc64?
> >
> > We could do that and theoretically it makes perfect sense
On Wed, 25 Feb 2015, Paul Durrant wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: 24 February 2015 18:00
> > To: Paul Durrant
> > Cc: Stefano Stabellini; xen-de...@lists.xensource.com; Ian Campbell
> > Subject: RE: [qemu-upstream-unstable bis
flight 35097 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 34731
test-amd64-i386-l
On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> On Tue, 24 Feb 2015, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > Now that we autodetect the use of dom0_mem and set autoballooning
> > > > correctly perhaps we should just revert a39b5bc6
On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> wrote:
> > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> >> On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez wrote:
> >> > On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel
> >> > wrote:
> >> >
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took the opportunity to also confirm that x86_32, x86
On 25/02/15 12:16, Ian Campbell wrote:
> In RFC style, rather than relying on the implicit assumptions of a
> particular C ABI.
>
> I have also confirmed, using the Python gdb extension technique in
> [0], that the struct offsets (in a Linux binary at least) are the same
> as described here.
>
> I
On Wed, 2015-02-25 at 12:16 +, Ian Campbell wrote:
> In RFC style, rather than relying on the implicit assumptions of a
> particular C ABI.
>
> I have also confirmed, using the Python gdb extension technique in
> [0], that the struct offsets (in a Linux binary at least) are the same
> as descr
On Wed, 2015-02-25 at 12:23 +, Andrew Cooper wrote:
> On 25/02/15 12:16, Ian Campbell wrote:
> > I have also confirmed, using the Python gdb extension technique in
> > [0], that the struct offsets (in a Linux binary at least) are the same
> > as described here.
[...]
> > []
> > http://stackove
On 02/25/2015 01:16 PM, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took th
On Wed, 2015-02-25 at 13:48 +0100, Jürgen Groß wrote:
> On 02/25/2015 01:16 PM, Ian Campbell wrote:
> > In RFC style, rather than relying on the implicit assumptions of a
> > particular C ABI.
> >
> > I have also confirmed, using the Python gdb extension technique in
> > [0], that the struct offset
On Tue, Feb 24, 2015 at 03:00:16PM +, Anthony PERARD wrote:
> On Tue, Feb 24, 2015 at 01:22:19PM +, Daniel P. Berrange wrote:
> > On Tue, Feb 24, 2015 at 01:15:57PM +, Anthony PERARD wrote:
> > > On Tue, Feb 24, 2015 at 12:46:44PM +, Daniel P. Berrange wrote:
> > > > On Tue, Feb 24,
On 25/02/15 12:16, Ian Campbell wrote:
> In RFC style, rather than relying on the implicit assumptions of a
> particular C ABI.
>
> I have also confirmed, using the Python gdb extension technique in
> [0], that the struct offsets (in a Linux binary at least) are the same
> as described here.
>
> I
Do not override this if the environment already has one.
Signed-off-by: Ian Jackson
---
branch-settings.osstest |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/branch-settings.osstest b/branch-settings.osstest
index 060ff4b..fe9561f 100644
--- a/branch-settings.osstest
+++
While testing Wei Liu's XSM series, I found that the adhoc testing
arrangements less than ideal.
After these patches, I can create `daily-cron-email-liuw' containing
To: ian.jack...@eu.citrix.com, Wei Liu
and (in my own account on the test controller) do this:
OSSTEST_EMAIL_HEADER=daily-cr
We don't want sg-report-flight digging through the `test history
database' (which doesn't really exist in standalone mode) looking for
a baseline.
Passing OLD_REVISION=NONE also avoids calling ./ap-fetch-version-old
for the current branch. This is useful particularly when the current
branch is os
When ap-fetch-version and ap-fetch-version-old are run on the osstest
controller but as a different user they should look in ~osstest, not
$HOME, for the master testing.git tree.
Signed-off-by: Ian Jackson
---
ap-fetch-version |2 +-
ap-fetch-version-old |2 +-
2 files changed, 2 ins
Defer computing this variable until it is going to be used.
The effect is that the fallback default value is assigned much later -
in start_email (cr-daily-branch) or send_bisection_email (cri-bisect).
Previously it was assigned as soon as cri-args-hostlists was read,
which is quite early.
In the
OSSTEST_NO_BASELINE disables the thing where cr-daily-branch decides
(based on information from sg-check-tested) that the baseline is
untested and therefore that it ought to do a baseline test instead of
testing the tip.
This whole feature is never correct in standalone mode, where there is
no use
Signed-off-by: Ian Jackson
---
cri-args-hostlists |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index ef4cebd..1acecb6 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -50,7 +50,9 @@ elif [ "x$1" = "x--like-real" ]; th
This is prefixed before the other computed prefixes. It makes it
easier to distinguish an adhoc cr-daily-branch test runs for a real
branch.
Signed-off-by: Ian Jackson
---
cri-args-hostlists |2 +-
cri-bisect |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/
When doing an OSSTEST_USE_HEAD test in infrastructure mode we would
like to use the real osstest mainline baseline as a reference for the
flight reports. (Rather than simply using the very version under test
as the baseline.)
So revert cf805fa8 "Allow forcing the use of current osstest HEAD for
b
On 25/02/15 11:14, Frediano Ziglio wrote:
> Translated address (in d->arch.vgic.{c,d}base) are now bus addresses
addresses
> which could not always be applied to the DT.
> Copy the original address from DT directly to get the original
addresses
> untraslated reg property which will give same d-
On 02/25/2015 04:34 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -27,35 +27,79 @@ static nodemask_t memory_nodes_parsed __initdata;
static nodemask_t processor_nodes_parsed __initdata;
static nodemask_t nodes_found __initdata;
On Wed, Feb 25, 2015 at 12:16:50PM +, Ian Campbell wrote:
> In RFC style, rather than relying on the implicit assumptions of a
> particular C ABI.
>
> I have also confirmed, using the Python gdb extension technique in
> [0], that the struct offsets (in a Linux binary at least) are the same
> a
Hi Dario,
In summary, I agree with you and will apply these comments discussed
in this thread to work out a RFC patch for it. Below is just some
reply to your question. :-)
2015-02-25 3:44 GMT-05:00 Dario Faggioli :
> On Tue, 2015-02-24 at 21:42 -0500, Meng Xu wrote:
>> Hi all,
>>
> Hello,
>
>> 2
On Wed, 2015-02-25 at 12:59 +, Andrew Cooper wrote:
> On 25/02/15 12:16, Ian Campbell wrote:
> > In RFC style, rather than relying on the implicit assumptions of a
> > particular C ABI.
> >
> > I have also confirmed, using the Python gdb extension technique in
> > [0], that the struct offsets (
Translated addresses (in d->arch.vgic.{c,d}base) are now bus addresses
which could not always be applied to the DT.
Copy the original addresses from DT directly to get the original
untranslated reg property which will give same d->arch.vgic.{c,d}base
values once translated again.
Signed-off-by: Fr
>>> On 25.02.15 at 14:11, wrote:
> On 02/25/2015 04:34 AM, Jan Beulich wrote:
> On 24.02.15 at 20:11, wrote:
>>> +{ [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
>>> +
>>> +static int node_to_pxm(int n);
>> I don't see why you need to reinstate this forward declaration.
>
> It is
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> Do not override this if the environment already has one.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> This is prefixed before the other computed prefixes. It makes it
> easier to distinguish an adhoc cr-daily-branch test runs for a real
> branch.
Do they not already get "adhoc" in the $subject? i.e. my commissioning
runs for the new arm crea
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> Defer computing this variable until it is going to be used.
>
> The effect is that the fallback default value is assigned much later -
> in start_email (cr-daily-branch) or send_bisection_email (cri-bisect).
> Previously it was assigned as so
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> OSSTEST_NO_BASELINE disables the thing where cr-daily-branch decides
> (based on information from sg-check-tested) that the baseline is
> untested and therefore that it ought to do a baseline test instead of
> testing the tip.
>
> This whole
On 02/25/15 03:30, Jan Beulich wrote:
On 24.02.15 at 19:29, wrote:
>> +/*
>> + * Test out special #GP handling for the VMware port 0x5658.
>> + * This is done in two "modes", j=0 and j=1. Testing 4
>> + * instructions (all the basic PIO) in both modes.
>> + *
>> + * T
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> We don't want sg-report-flight digging through the `test history
> database' (which doesn't really exist in standalone mode) looking for
> a baseline.
>
> Passing OLD_REVISION=NONE also avoids calling ./ap-fetch-version-old
> for the current
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> When doing an OSSTEST_USE_HEAD test in infrastructure mode we would
> like to use the real osstest mainline baseline as a reference for the
> flight reports. (Rather than simply using the very version under test
> as the baseline.)
>
> So re
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> When ap-fetch-version and ap-fetch-version-old are run on the osstest
> controller but as a different user they should look in ~osstest, not
> $HOME, for the master testing.git tree.
>
> Signed-off-by: Ian Jackson
But what if they are run n
On 02/25/2015 05:35 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, wrote:
@@ -121,10 +123,12 @@ struct npfec {
#define _MEMF_exact_node 4
#define MEMF_exact_node (1U<<_MEMF_exact_node)
#define _MEMF_node8
-#define MEMF_node(n) n)+1)&0xff)<<_MEMF_node)
+#define MEMF_node
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took the opportunity to also confirm that x86_32, x86
On Fri, 2015-02-13 at 02:07 +, Xu, Quan wrote:
> I try to redefine tpm2_types.h, deleting 'UINT16, UINT32 ..' and changing
> 'TPM_HANDLE ...' to ' TPM2_HANDLE ..',
> Or, could you give some advice? Thanks.
Perhaps make stubdom/vtpmmgr/types.h with these and use it for both?
Or switch to th
On 25/02/15 13:39, Ian Campbell wrote:
>
> + * Guest transmit
> + * ==
> + *
> + * Ring slot size is 12 octets, however not all request/response
> + * structs use the full size.
> + *
> + * tx request data (netif_tx_request_t)
> + *
> + *
> + *0
On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
> On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> > On Tue, 24 Feb 2015, Ian Campbell wrote:
> > > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > > Now that we autodetect the use of dom0_mem and set autoball
On Wed, 25 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
> > On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> > > On Tue, 24 Feb 2015, Ian Campbell wrote:
> > > > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > > > Now that
>>> On 25.02.15 at 14:30, wrote:
> On 02/25/2015 05:35 AM, Jan Beulich wrote:
> On 24.02.15 at 20:11, wrote:
>>> @@ -121,10 +123,12 @@ struct npfec {
>>> #define _MEMF_exact_node 4
>>> #define MEMF_exact_node (1U<<_MEMF_exact_node)
>>> #define _MEMF_node8
>>> -#define MEMF_n
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This unwraps XEN_BACKEND from depending on XEN_DOM0, it
> instead makes it depend on the possible x86 backends and
> under what scenerios its allowed under ARM. This is as per
> the agreed upon Xen Kconfig changes [0].
flight 35312 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) running in 34247
[st=running!]
test-a
On 24/02/15 06:27, Juergen Gross wrote:
> On 02/19/2015 07:07 PM, David Vrabel wrote:
>> On 18/02/2015 06:51, Juergen Gross wrote:
>>> +{
>>> +unsigned long pfn;
>>> +unsigned long area_start, area_end;
>>> +unsigned i;
>>> +
>>> +for (i = 0; i < XEN_N_RESERVED_AREAS; i++) {
>>> +
>
On Wed, 25 Feb 2015, Stefano Stabellini wrote:
> On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> > wrote:
> > > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> > >> On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez
> > >> wrote:
> > >> > O
On 25/02/15 14:17, Stefano Stabellini wrote:
> On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> This unwraps XEN_BACKEND from depending on XEN_DOM0, it
>> instead makes it depend on the possible x86 backends and
>> under what scenerios its allowed under ARM. This is
On Thu, 2015-02-19 at 15:13 +, Ian Campbell wrote:
> On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
> > >> Although, I think the debug message in bad_trap is useful to keep. It
> > >> may be handy to have the HSR and the guest stack trace printed if Xen
> > >> hit the condition.
> > >
On Thu, 2015-02-19 at 18:57 +, Julien Grall wrote:
> Hi Ian,
>
> On 19/02/15 17:39, Ian Campbell wrote:
> > ... and make it tunable via the command line.
> >
> > 1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
> > which is a lot. 1/32 of RAM seems more reasonable. Also drop t
On 25/02/15 14:32, Ian Campbell wrote:
> On Thu, 2015-02-19 at 15:13 +, Ian Campbell wrote:
>> On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
> Although, I think the debug message in bad_trap is useful to keep. It
> may be handy to have the HSR and the guest stack trace printed
On Wed, 25 Feb 2015, David Vrabel wrote:
> On 25/02/15 14:17, Stefano Stabellini wrote:
> > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez"
> >>
> >> This unwraps XEN_BACKEND from depending on XEN_DOM0, it
> >> instead makes it depend on the possible x86 backends and
>
On Wed, Feb 25, 2015 at 03:27:13PM +0100, pedro wrote:
> offset and size are of type uint16_t so the %lu gives a warning
> A %u specifier, the same used in size makes gcc happy
>
> Signed-off-by: pedro
Acked-by: Wei Liu
Thanks for the patch.
One question though. Is "pedro" your real full name
offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Signed-off-by: pedro
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xe
On Thu, 2015-02-19 at 16:20 +, Julien Grall wrote:
> Regardless the question,this patch look good to me. With the 2 nits I
> spotted on my previous email:
>
> Reviewed-by: Julien Grall
Thanks, applied both patches (with nits fixed)
>
> Regards,
>
__
BTW, you should send this patch to net...@vger.kernel.org.
Have a look at Documentation/networking/netdev-FAQ.txt for more
information. Feel free to ask me any question if you have doubt.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://l
Please ignore this series. I will send out another version that's
simpler.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Non-anonymous allocations with this flag set should - for the purpose
of the availability check - be treated just like anonymous ones, as
they wouldn't lead to a reduction of ->outstanding_pages.
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -617,7 +61
Original the structure was memset to a poison value. That prevented
_dispose to be made idempotent. We should stop doing so.
Memseting the structure to 0 makes all pointers in structure become
NULL, which can be handled by free().
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
to
These functions are not generated, so we need to do it by hand.
Functions list:
libxl_bitmap_dispose
libxl_string_list_dispose
libxl_key_value_list_dipose
libxl_cpuid_dispose
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/libxl.c | 11 +--
tools/libx
On Thu, 2015-02-19 at 18:12 +, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which vIRQ is allocated by Xen for a specific domain.
>
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used late
Remove a redundant statement from parse_dom0_mem() and refuse bogus
ranges (with a separator other than a dash) passed to
parse_dom0_max_vcpus(). Fix coding style issues in the latter function
at the same time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domai
Free the JSON string after use to avoid memory leak. With this change
testidl is valgrind clean.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
tools/libxl/gentest.py | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/gentest.py b/tools/libx
1 - 100 of 187 matches
Mail list logo
