flight 81613 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 79947
build-amd64
>>> On 09.02.16 at 18:32, wrote:
> On Tue, Feb 9, 2016 at 10:17 AM, Jan Beulich wrote:
>
>> >>> On 05.02.16 at 22:22, wrote:
>> > --- a/xen/include/public/memory.h
>> > +++ b/xen/include/public/memory.h
>> > @@ -423,11 +423,20 @@ struct xen_mem_access_op {
>> > /* xenmem_access_t */
>> >
Signed-off-by: Harmandeep Kaur
---
tools/libxc/xc_offline_page.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_offline_page.c b/tools/libxc/xc_offline_page.c
index bc91d51..3248a34 100644
--- a/tools/libxc/xc_offline_page.c
+++ b/tools/libxc/xc_offline_page.c
Signed-off-by: Harmandeep Kaur
---
tools/libxc/xc_tbuf.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
index 695939a..f06f566 100644
--- a/tools/libxc/xc_tbuf.c
+++ b/tools/libxc/xc_tbuf.c
@@ -70,9 +70,13 @@ int xc_tbuf_get_size(xc_interface
On Tue, 2016-02-09 at 20:01 +, Andrew Cooper wrote:
> This is a misc assortment of patches to fix the build with Clang 3.5.
FWIW clang 3.5 appears to be in Debian Jessie, which means the path to
having a build job in osstest is far shorter than it once was if anyone is
interested in adding suc
Hi Harmandeep,
Thanks for this patch.
On Wed, 2016-02-10 at 14:37 +0530, Harmandeep Kaur wrote:
>
In general, I think it would be best if the subject is a bit more
"explicative", and if you add a few words of changelog, here, above the
S-o-b.
In this case, this could be something like this.
Sub
On Wed, 2016-02-10 at 11:51 +1100, Alex Braunegg wrote:
> Many thanks for the detailed information and analysis - so potentially
> chasing something that cannot occur to a guest if the Windows PV Drivers
> are not installed.
>
> > You might want to change this now. ;-)
>
> No issue there - the gu
On Wed, 2016-02-10 at 14:39 +0530, Harmandeep Kaur wrote:
>
What I just said about the other patch ("libxc: Fix CID 1351225
resource leak") applies here as well, of course. :-)
About the code...
> --- a/tools/libxc/xc_tbuf.c
> +++ b/tools/libxc/xc_tbuf.c
> @@ -70,9 +70,13 @@ int xc_tbuf_get_size(
On Tue, 2016-02-09 at 17:39 +0100, Luis R. Rodriguez wrote:
>
> > I wouldn't bet on it always doing the right thing with 3rd party components
> > like qemu-xen.
>
> Hrm, so how can I get the proper maintainer ? For my case I need to split this
> series up into 5 or 6 series for 5 separate trees:
On Tue, 2016-02-09 at 17:53 +0100, Luis R. Rodriguez wrote:
>
> > > === PCI passthrough capability has been enabled ===
> > > CCqemu-nbd.o
> > > In file included from ./xen-config-host.h:19:0,
> > > from ./config-host.h:18,
> > > from ./qemu-common.h:33,
> >
flight 38734 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38734/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38724
jobs:
build-amd64 pass
build-armhf
On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering wrote:
> > On Tue, Feb 09, Luis R. Rodriguez wrote:
> >
> > > Thanks so it seems the other option is to bump the release, can that
> > > be decided? What's the process for deciding that?
> >
On Tue, 2016-02-09 at 21:44 -0800, Luis R. Rodriguez wrote:
> If I just cd into that directory (tools/qemu-xen-traditional-dir/),
> run ./configure and build it fails with:
This doesn't work/isn't supported. The Xen build system includes support
for recursing properly into qemu-xen-traditional-dir
On Wed, 2016-02-10 at 10:28 +0100, Dario Faggioli wrote:
> Hi Harmandeep,
>
> Thanks for this patch.
>
> On Wed, 2016-02-10 at 14:37 +0530, Harmandeep Kaur wrote:
> >
> In general, I think it would be best if the subject is a bit more
> "explicative", and if you add a few words of changelog, her
On 09/02/16 20:01, Andrew Cooper wrote:
> Clang doesn't like mixing const and non-const data in the same section. Move
> zero_page into .bss.page_aligned.const and wildcard .bss.page_aligned when
> linking.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunlap
> ---
> CC: Jan Beulich
> CC
On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote:
> I agree on the first two paragraphs.
> > > For the third paragraph, the rebuttal is that the exynos5800 and
> > > exynos5422 based SoCs can have both clusters on at the same time. Hence,
> > > the third paragrapah comment will have to be
On Tue, 2016-02-09 at 05:35 -0700, Jan Beulich wrote:
> > On 09.02.16 at 13:17, wrote:
> > I don't think sometimes returning the number of things you did and
> > sometimes returning zero makes any sense. My suggestion would be
> > either
> > make "nr_mfns" bidirectional (as similar fields are in
On 08/02/16 16:36, Ian Campbell wrote:
> On Mon, 2016-02-08 at 16:23 +, Tim Deegan wrote:
>> At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote:
>>> The type of the pointer to a bitmap is not interesting; it does not
>>> affect the
>>> representation of the block of bits being pointed t
% Xen PV IOMMU interface
% Malcolm Crossley <>
Paul Durrant <>
% Draft D
Introduction
Revision History
Version Date Changes
--- ---
Currently the ops are X86 only due to a dependency on the
X86 only B2M implementation.
Foreign ops conform to draft D of PV-IOMMU design.
XSM control been implemented to allow full security control of
these priviledged operatins.
Page references and page locking are taken before using B2M
interf
Signed-off-by: Malcolm Crossley
--
Cc: jbeul...@suse.com
Cc: andrew.coop...@citrix.com
Cc: ian.campb...@citrix.com
Cc: k...@xen.org
Cc: t...@xen.org
Cc: xen-devel@lists.xen.org
---
xen/arch/x86/x86_64/compat/entry.S | 2 ++
xen/arch/x86/x86_64/entry.S| 2 ++
xen/common/Makefile
If IOMMU driver does not implement lookup_page function then it returns -ENOMEM.
Returns 0 on success and any other value on failure.
Signed-off-by: Malcolm Crossley
--
Cc: jbeul...@suse.com
Cc: xen-devel@lists.xen.org
---
xen/drivers/passthrough/iommu.c | 21 +
xen/include/
Add a pointer to the page struct which refers to the head of
m2b tracking structure for that page.
Atomically add a PGC bit to the page struct when setting the pointer to
the m2b tracking structure.
Adding elements to the per page m2b tracking structure is done via a
RCU protected linked list.
C
Implement above ops according to PV-IOMMU design draft D.
Currently restricted to hardware domains only due to RFC status.
Signed-off-by: Malcolm Crossley
--
Cc: jbeul...@suse.com
Cc: k...@xen.org
Cc: t...@xen.org
Cc: andrew.coop...@citrix.com
Cc: xen-devel@lists.xen.org
---
xen/common/pv_iommu
If the hardware domain is relaxed IOMMU mode, then allow the
hardware domain to pre IOMMU map host memory so that foreign IOMMU maps
of guest memory are not necessary and only foreign lookups are required.
The security model is not weakened because the hardware domain in relaxed
IOMMU mode already
Function does not need to handle shared EPT use of IOMMU as core code
already handles this.
Signed-off-by: Malcolm Crossley
--
Cc: kevin.t...@intel.com
Cc: feng...@intel.com
Cc: xen-devel@lists.xen.org
---
xen/drivers/passthrough/vtd/iommu.c | 31 +++
xen/drivers/pass
On 09/02/16 20:01, Andrew Cooper wrote:
> Clang objects to having multiple initialisers when creating an array.
>
> As this warning is useful for spotting obscure bugs, disabling it is
> unhelpful. Instead, fix our two deliberate usecases.
>
> In the p2m-ept case, pull the array out into a helpe
Adding some CCs.
On Fri, 2016-02-05 at 11:52 +, Anthony PERARD wrote:
> On Fri, Feb 05, 2016 at 06:30:25AM +, osstest service owner wrote:
> > flight 80469 qemu-mainline real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/80469/
> >
> > Regressions :-(
> >
> > Tests which d
On 10/02/16 10:06, Ian Campbell wrote:
> On Tue, 2016-02-09 at 05:35 -0700, Jan Beulich wrote:
>>> On 09.02.16 at 13:17, wrote:
>>> I don't think sometimes returning the number of things you did and
>>> sometimes returning zero makes any sense. My suggestion would be
>>> either
>>> make "nr_mfns"
On Wed, 2016-02-10 at 10:07 +, Andrew Cooper wrote:
> On 08/02/16 16:36, Ian Campbell wrote:
> > On Mon, 2016-02-08 at 16:23 +, Tim Deegan wrote:
> > > At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote:
> > > > The type of the pointer to a bitmap is not interesting; it does not
> >
On Tue, 2016-02-09 at 16:50 +, Stefano Stabellini wrote:
> > @@ -2218,15 +2127,10 @@ EOF
> > fi
> >
> > if test "$xen_pci_passthrough" != "no"; then
> > - if test "$xen" = "yes" && test "$linux" = "yes" &&
> > - test "$xen_ctrl_version" -ge 340; then
> > + if test "$xen" = "yes" && tes
This RFC series implements the PV-IOMMU interface according to the PV-IOMMU
design draft D.
The PV-IOMMU interface is currently restricted to being used by the hardware
domain only as non hardware domain callers have not been fully tested yet.
Significant effort was put into implementing a m2b tr
I forgot to CC xen-devel for the cover letter for this series.
You can access the cover letter in the xen-devel archives here:
http://lists.xen.org/archives/html/xen-devel/2016-02/msg01441.html
On 10/02/16 10:10, Malcolm Crossley wrote:
> Signed-off-by: Malcolm Crossley
> --
> Cc: jbeul...@suse.c
On 09/02/16 17:05, Jan Beulich wrote:
On 09.02.16 at 17:21, wrote:
>> Signed-off-by: Andrew Cooper
> I'm sorry for the breakage / not noticing.
>
>> ---
>> CC: Jan Beulich
>> CC: Tim Deegan
>> CC: Ian Campbell
>> CC: Daniel De Graaf
>>
>> Is this actually an appropraite fix? Software re
At 20:01 + on 09 Feb (1455048102), Andrew Cooper wrote:
> Clang notices more unused functions than GCC.
>
> * sh_next_page() is only used at GUEST_PAGING_LEVELS=2, so remove it from the
>other guest level translation units
> * rcu_batch_after() is completely unused.
> * Various of the C
On Wed, 10 Feb 2016, Ian Campbell wrote:
> On Tue, 2016-02-09 at 16:50 +, Stefano Stabellini wrote:
> > > @@ -2218,15 +2127,10 @@ EOF
> > > fi
> > >
> > > if test "$xen_pci_passthrough" != "no"; then
> > > - if test "$xen" = "yes" && test "$linux" = "yes" &&
> > > - test "$xen_ctrl_versi
>>> On 10.02.16 at 11:39, wrote:
> On 09/02/16 17:05, Jan Beulich wrote:
> On 09.02.16 at 17:21, wrote:
>>> Signed-off-by: Andrew Cooper
>> I'm sorry for the breakage / not noticing.
>>
>>> ---
>>> CC: Jan Beulich
>>> CC: Tim Deegan
>>> CC: Ian Campbell
>>> CC: Daniel De Graaf
>>>
>>> Is
This is most easily explained by the commit log of the first patch:
Xen 4.2 become unsupported upstream in 09/2015 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
The xc version is now always present.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
include/hw/xen/xen_common.h | 6 --
xen-hvm.c | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common
Now that 4.2 and earlier are no longer supported "xc_interface *" is
always the right type for the xc interface handle.
With this we can also simplify the handling of the xenforeignmemory
compatibility wrapper by making xenforeignmemory_handle ==
xc_interface, instead of an xc_interface* and remov
We assume (and check for in configure) 4.2 or later now. In reality
all of the removed checks are for far older versions.
FMT_ioreq_size is no longer needed.
Signed-off-by: Ian Campbell
---
v2: Drop FMT_ioreq_size too
---
hw/display/xenfb.c | 7 ---
xen-hvm.c | 19 ++--
Now that we no longer support Xen 4.2 and earlier only the <470 case
needs this so it can live with all the others.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
include/hw/xen/xen_common.h | 34 ++
1 file changed, 14 insertions(+), 20 deletions
Xen 4.2 become unsupported upstream in 09/2015 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
Therefore drop support for Xen 4.1 and earlier which removes a whole
pile of compatibility
Dario Faggioli writes ("Re: [PATCH] libxc: Fix CID 1351228 resource leak"):
> On Wed, 2016-02-10 at 14:39 +0530, Harmandeep Kaur wrote:
> >
> What I just said about the other patch ("libxc: Fix CID 1351225
> resource leak") applies here as well, of course. :-)
>
> About the code...
...
> > if
Dario Faggioli writes ("Re: [PATCH] libxc: Fix CID 1351225 resource leak"):
> That being said, this case is very simple, so I'll leave it to the
> tools maintainers to tell whether they want something like what I
> described above in place or not.
I agree that what you suggest would be better. Th
There's no reason to defer this until the connect phase, and in fact
there are frontend implementations expecting this to be available
earlier. Move it into the probe function.
Signed-off-by: Jan Beulich
Cc: Bob Liu
---
drivers/block/xen-blkback/xenbus.c | 13 -
1 file changed, 8
Avoid leaking the mapping of the m2p in one of the possible failure cases.
Coverity CID 1351225
Signed-off-by: Harmandeep Kaur
---
v2: update commit message and changelog
---
tools/libxc/xc_offline_page.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_offline
"max" is rather ambiguous and carries pretty little meaning, the more
that there are also "max_queues" and "max_ring_page_order". Make this
"max_indirect_segments" instead, and at once change the type from int
to uint (to match the respective variable's type).
Signed-off-by: Jan Beulich
---
driv
Harmandeep Kaur writes ("[PATCH v2] libxc: fix leak in xc_offline_page error
path"):
> Avoid leaking the mapping of the m2p in one of the possible failure cases.
>
> Coverity CID 1351225
>
> Signed-off-by: Harmandeep Kaur
Thanks.
Acked-by: Ian Jackson
It is conventional, when you post a v2,
On Wed, 10 Feb 2016, Ian Campbell wrote:
> Adding some CCs.
>
> On Fri, 2016-02-05 at 11:52 +, Anthony PERARD wrote:
> > On Fri, Feb 05, 2016 at 06:30:25AM +, osstest service owner wrote:
> > > flight 80469 qemu-mainline real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/80
On Wed, 10 Feb 2016, Ian Campbell wrote:
> Xen 4.2 become unsupported upstream in 09/2015 (see
> http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
> interfaces provided by the toolstack libraries go 4.2 and 4.3 are
> indistinguishable.
>
> Therefore drop support for Xen 4.1 and
On Wed, 10 Feb 2016, Ian Campbell wrote:
> We assume (and check for in configure) 4.2 or later now. In reality
> all of the removed checks are for far older versions.
>
> FMT_ioreq_size is no longer needed.
>
> Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
> v2: Drop FMT_ioreq_
El 9/2/16 a les 14:24, Jan Beulich ha escrit:
On 08.02.16 at 20:03, wrote:
>> * `eflags`: all user settable bits are clear.
>
> The word "user" here can be mistaken. Perhaps better "all modifiable
> bits"?
>
>> All other processor registers and flag bits are unspecified. The OS is in
>> cha
On Wed, 2016-02-10 at 11:53 +, Stefano Stabellini wrote:
> On Wed, 10 Feb 2016, Ian Campbell wrote:
> > Adding some CCs.
> >
> > On Fri, 2016-02-05 at 11:52 +, Anthony PERARD wrote:
> > > On Fri, Feb 05, 2016 at 06:30:25AM +, osstest service owner
> > > wrote:
> > > > flight 80469 qem
On Wed, 10 Feb 2016, Ian Campbell wrote:
> This is most easily explained by the commit log of the first patch:
>
> Xen 4.2 become unsupported upstream in 09/2015 (see
> http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
> interfaces provided by the toolstack libraries
> -Original Message-
[snip]
> > ./configure of QEMU fail with:
> > "ERROR: invalid trace backends
> > Please choose supported trace backends."
> >
> > They have remove the "stderr" tracebackend, and replaced it by "log".
> Which
> > also became the default. I have not look at what t
On Wed, 2016-02-10 at 12:03 +, Ian Campbell wrote:
> On Wed, 2016-02-10 at 11:53 +, Stefano Stabellini wrote:
> > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > Adding some CCs.
> > >
> > > On Fri, 2016-02-05 at 11:52 +, Anthony PERARD wrote:
> > > > On Fri, Feb 05, 2016 at 06:30:25AM
El 10/2/16 a les 12:21, Jan Beulich ha escrit:
> "max" is rather ambiguous and carries pretty little meaning, the more
> that there are also "max_queues" and "max_ring_page_order". Make this
> "max_indirect_segments" instead, and at once change the type from int
> to uint (to match the respective v
flight 80731 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
77858
te
On 02/02/16 04:48, Wu, Feng wrote:
> +static void vmx_pi_do_resume(struct vcpu *v)
> +{
> +unsigned long flags;
> +spinlock_t *pi_block_list_lock;
> +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> +ASSERT(!test_bit(_VPF_blocked, &v->pause_flags
El 10/2/16 a les 12:18, Jan Beulich ha escrit:
> There's no reason to defer this until the connect phase, and in fact
> there are frontend implementations expecting this to be available
> earlier. Move it into the probe function.
>
> Signed-off-by: Jan Beulich
Looks fine.
Acked-by: Roger Pau Mo
When mapping large BARs (e.g. the frame buffer of a graphics card) the
overhead of establishing such mappings using only 4k pages has,
particularly after the XSA-125 fix, become unacceptable. Alter the
XEN_DOMCTL_memory_mapping semantics once again, so that there's no
longer a fixed amount of guest
On 28/01/16 05:12, Feng Wu wrote:
> This is the core logic handling for VT-d posted-interrupts. Basically it
> deals with how and when to update posted-interrupts during the following
> scenarios:
> - vCPU is preempted
> - vCPU is slept
> - vCPU is blocked
>
> When vCPU is preempted/slept, we upda
1: avoid flush IPI when possible
2: use CLFLUSHOPT when available
3: rename X86_FEATURE_{CLFLSH -> CLFLUSH}
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
QEMU upstream commit ed7f5f1d8db0 ("trace: convert stderr backend to
log") renamed the stderr trace backend to log, which breaks the xen
build when pointed at a QEMU tree after that point:
./configure of QEMU fail with:
"ERROR: invalid trace backends
Please choose supported trace backends.
>>> On 10.02.16 at 13:01, wrote:
> El 9/2/16 a les 14:24, Jan Beulich ha escrit:
> On 08.02.16 at 20:03, wrote:
>>> The layout of each entry in the module structure is the following:
>>>
>>> 0 ++
>>>| paddr | Physical address of the module.
>>> 4 +--
Since CLFLUSH, other than WBINVD, is a coherency domain wide flush,
there's no need to IPI other CPUs if this is the only flushing being
requested. (As a secondary change, move a local variable into the scope
where it's actually needed.)
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+
Also drop an unnecessary va adjustment in the code being touched.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -139,10 +139,12 @@ unsigned int flush_area_local(const void
c->x86_clflush_size && c->x86_cache_size && sz &&
((
This is both more natural and in line with a Linux change (between 3.14
and 3.15).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -206,7 +206,7 @@ static void __init early_cpu_detect(void
c->x86_mask = eax & 15;
edx &= ~cleared_caps[
>>> On 09.02.16 at 21:01, wrote:
> --- a/xen/common/rcupdate.c
> +++ b/xen/common/rcupdate.c
> @@ -141,12 +141,6 @@ static inline int rcu_batch_before(long a, long b)
> return (a - b) < 0;
> }
>
> -/* Is batch a after batch b ? */
> -static inline int rcu_batch_after(long a, long b)
> -{
>
>>> On 09.02.16 at 21:01, wrote:
> Clang doesn't support the %z modifier. Replace both uses with an explicit l
> suffix, and cover the changes with BUILD_BUG_ON()s
Ugly. Really ugly. But well - what do you do.
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
On 10/02/16 13:06, Jan Beulich wrote:
On 09.02.16 at 21:01, wrote:
>> --- a/xen/common/rcupdate.c
>> +++ b/xen/common/rcupdate.c
>> @@ -141,12 +141,6 @@ static inline int rcu_batch_before(long a, long b)
>> return (a - b) < 0;
>> }
>>
>> -/* Is batch a after batch b ? */
>> -static in
>>> On 09.02.16 at 21:01, wrote:
> Clang objects to having multiple initialisers when creating an array.
>
> As this warning is useful for spotting obscure bugs, disabling it is
> unhelpful. Instead, fix our two deliberate usecases.
Ugly again, but - well ...
> --- a/xen/arch/x86/mm/p2m-ept.c
On Mon, Feb 08, 2016 at 04:57:46PM +0530, Jayachandran Chandrashekaran Nair
wrote:
> Lorenzo,
>
> On Fri, Feb 5, 2016 at 3:17 PM, Lorenzo Pieralisi
> wrote:
> > On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair
> > wrote:
> >
> > [...]
> >
> >> pci_host_acpi.c is a gen
flight 80733 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 7772
>>> On 09.02.16 at 21:01, wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
>
> What is the GCC version check supposed to be achieving here? GCC has
> supported this syntax since 3.0
This is best answered by looking at where we've got these headers
from - the gnu-efi package. It h
On 10/02/16 13:31, Jan Beulich wrote:
On 09.02.16 at 21:01, wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>>
>> What is the GCC version check supposed to be achieving here? GCC has
>> supported this syntax since 3.0
> This is best answered by looking at where we've got t
On 10/02/16 13:22, Jan Beulich wrote:
On 09.02.16 at 21:01, wrote:
>> Clang objects to having multiple initialisers when creating an array.
>>
>> As this warning is useful for spotting obscure bugs, disabling it is
>> unhelpful. Instead, fix our two deliberate usecases.
> Ugly again, but - w
>>> On 10.02.16 at 14:50, wrote:
> On 10/02/16 13:22, Jan Beulich wrote:
> On 09.02.16 at 21:01, wrote:
>>> Clang objects to having multiple initialisers when creating an array.
>>>
>>> As this warning is useful for spotting obscure bugs, disabling it is
>>> unhelpful. Instead, fix our two d
On Wed, 2016-02-10 at 11:14 +, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [PATCH] libxc: Fix CID 1351228 resource
> leak"):
> > On Wed, 2016-02-10 at 14:39 +0530, Harmandeep Kaur wrote:
> > >
> > What I just said about the other patch ("libxc: Fix CID 1351225
> > resource leak") applies
On 10/02/16 14:03, Jan Beulich wrote:
On 10.02.16 at 14:50, wrote:
>> On 10/02/16 13:22, Jan Beulich wrote:
>> On 09.02.16 at 21:01, wrote:
Clang objects to having multiple initialisers when creating an array.
As this warning is useful for spotting obscure bugs, disabling
On Wed, 10 Feb 2016, Ian Campbell wrote:
> QEMU upstream commit ed7f5f1d8db0 ("trace: convert stderr backend to
> log") renamed the stderr trace backend to log, which breaks the xen
> build when pointed at a QEMU tree after that point:
>
> ./configure of QEMU fail with:
> "ERROR: invalid trace bac
On 10/02/16 12:31, Jan Beulich wrote:
> When mapping large BARs (e.g. the frame buffer of a graphics card) the
> overhead of establishing such mappings using only 4k pages has,
> particularly after the XSA-125 fix, become unacceptable. Alter the
> XEN_DOMCTL_memory_mapping semantics once again, so
On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> On Wed, 10 Feb 2016, Ian Campbell wrote:
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 5688a7c..76a2235 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -228,7 +228,7 @@ qemu-xen-dir-force-update: qemu
On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > diff --git a/tools/Makefile b/tools/Makefile
> > > index 5688a7c..76a2235 100644
> > > --- a/tools/Makefile
> > > +++ b/t
On Wed, 2016-02-10 at 14:27 +, Ian Campbell wrote:
> On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index
On Wed, 10 Feb 2016, Ian Campbell wrote:
> On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index 5688a7c..76a
On Wed, 2016-02-10 at 14:27 +, Ian Campbell wrote:
> On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index
On Wed, 10 Feb 2016, Ian Campbell wrote:
> On Wed, 2016-02-10 at 14:27 +, Ian Campbell wrote:
> > On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > > > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > > > diff --
On Wed, 10 Feb 2016, Ian Campbell wrote:
> On Wed, 2016-02-10 at 14:27 +, Ian Campbell wrote:
> > On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrote:
> > > > On Wed, 10 Feb 2016, Ian Campbell wrote:
> > > > > diff --
El 10/2/16 a les 13:53, Jan Beulich ha escrit:
On 10.02.16 at 13:01, wrote:
>> El 9/2/16 a les 14:24, Jan Beulich ha escrit:
>> On 08.02.16 at 20:03, wrote:
* 2. HVMlite with (or capable to) PCI-passthrough
---
The current
On Wed, 2016-02-10 at 14:44 +, Stefano Stabellini wrote:
> > > > But, if you use '--check-backend --backend' (no 's') instead, the
> > > > check
> > > > would works with qemu-xen >= 4.3
> >
> > BTW, I think those correspond to
> >
> > qemu-mainline == QEMU 2.5.50
> > qemu-xen-unstable == QEMU
On 10/02/16 12:56, Jan Beulich wrote:
> Since CLFLUSH, other than WBINVD, is a coherency domain wide flush,
I can't parse this sentence.
CLFUSH states "Invalidates from every level of the cache hierarchy in
the cache coherence domain"
WBINVD however states "The instruction then issues a special-
On Sun, Feb 07, 2016 at 08:45:03PM -0600, Doug Goldstein wrote:
> This is just suppose to do a simple compile test on Travis CI. Currently
> due to linux86 (bcc/bin86/dev86) not being whitelisted the tools cannot
> be built.
>
> Signed-off-by: Doug Goldstein
FWIW:
Reviewed-by: Wei Liu
___
On 10/02/16 12:57, Jan Beulich wrote:
> This is both more natural and in line with a Linux change (between 3.14
> and 3.15).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.
On 10/02/16 12:57, Jan Beulich wrote:
> Also drop an unnecessary va adjustment in the code being touched.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -139,10 +139,12 @@ unsigned int flush_area_local(const void
> c->x86_clflush
On Wed, 2016-02-10 at 14:51 +, Stefano Stabellini wrote:
> On Wed, 10 Feb 2016, Ian Campbell wrote:
> > On Wed, 2016-02-10 at 14:27 +, Ian Campbell wrote:
> > > On Wed, 2016-02-10 at 14:18 +, Anthony PERARD wrote:
> > > > On Wed, Feb 10, 2016 at 02:14:13PM +, Stefano Stabellini wrot
On 02/10/2016 09:51 AM, Roger Pau Monné wrote:
The detection of local APIC and IO APICs is quite isolated from each
other, and the failure to find any IO APICs should not prevent local
APICs from being enabled. Although I don't think there's any hardware
with this setup, such configuration would
On Wed, 2016-02-10 at 12:09 +, Paul Durrant wrote:
> > I would prefer if libxl also kicked off qemu with a default events file
> that enabled logging from the platform device).
FWIW from upstream commit 10578a257d94 it appears to be possible to do this
from the QEMU command line with "-trace e
>>> On 10.02.16 at 16:03, wrote:
> On 10/02/16 12:57, Jan Beulich wrote:
>> Also drop an unnecessary va adjustment in the code being touched.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -139,10 +139,12 @@ unsigned int flush_area_loca
1 - 100 of 175 matches
Mail list logo
