On 7/15/2016 9:51 AM, Corneliu ZUZU wrote:
Turn atomic_inc_return and atomic_dec_return atomic.h macros to inline
functions. Adjust README.LinuxPrimitives in the process.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Stefano Stabellini
---
Changed since v3:
* update README.LinuxPrimitives file
ARM ():
* add atomic_add_unless() wrapper over __atomic_add_unless()
(for common-code interface, i.e. )
X86 ():
* implement missing functions atomic_{sub,inc,dec}_return(), atomic_add_unless()
* implement missing macro atomic_xchg()
COMMON ():
* add prototypes for the aforementioned newly imple
Turn atomic_inc_return and atomic_dec_return atomic.h macros to inline
functions. Adjust README.LinuxPrimitives in the process.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Stefano Stabellini
---
Changed since v3:
* update README.LinuxPrimitives file
---
xen/arch/arm/README.LinuxPrimitives | 18
This wouldn't let me make a param of a function that used atomic_read() const.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
---
Changed since v3:
---
xen/include/asm-arm/atomic.h | 2 +-
xen/include/asm-x86/atomic.h | 2 +-
xen/include/xen/atomic.h
Create a common-side to establish, among others, prototypes of
atomic functions called from common-code. Done to avoid introducing
inconsistencies between arch-side headers when we make subtle
changes to one of them. Some arm-side macros had to be turned into inline
functions in the process (also
Place atomic_inc_and_test() implementation after atomic_inc().
Also empty line fix.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Andrew Cooper
---
Changed since v3:
---
xen/include/asm-x86/atomic.h | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
di
Reorder macro definitions to match x86-side.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Stefano Stabellini
---
Changed since v3:
---
xen/include/asm-arm/atomic.h | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/a
Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h
to asm-arm/atomic.h. Adjust README.LinuxPrimitives in the process.
Also empty line fixes.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Stefano Stabellini
---
Changed since v3:
* update README.LinuxPrimitives file
---
Corneliu ZUZU (7):
1/7: asm-arm/atomic.h: fix arm32|arm64 macros duplication
Reviewed-by: Stefano Stabellini
Changed:
* update README.LinuxPrimitives file
2/7: asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement
Reviewed-by: Andrew Cooper
Changed:
3/7:
Commit 095497ffc66b7f031ff2a17f1e50f5cb105ce588 ("vnc-enc-tight: use
thread local storage for palette") introduced a regression with Xen:
Since this commit qemu used as a device model is no longer capable
to register Xenstore watches (that's the effect visible to a user).
Reverting this commit make
Add support for debugging memory allocation statistics to xenstored.
Specifying "-M " on the command line will enable the feature.
Whenever xenstored receives SIGUSR1 it will dump out a full talloc
report to . This helps finding e.g. memory leaks in xenstored.
Signed-off-by: Juergen Gross
---
To
xenstored has a memory leak when setting watches: a no longer active
watch which fired in the past will still use some memory. This is
critical for long running connections to xenstored like the qemu
process serving as a qdisk backend for dom0. It will use some few
kB in xenstored for each domain c
Use a temporary memory context for memory allocations when firing
watches. This will avoid leaking memory in case of long living
connections and/or xenstore entries.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c| 69 ++
tools/xenstore/xe
In order to be able to avoid leaving temporary memory allocated after
processing of a command in xenstored call all command functions with
the temporary "in" context. Each function can then make use of that
temporary context for allocating temporary memory instead of either
leaving that memory allo
flight 97301 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 96791
test-amd64-amd64-li
This run is configured for baseline tests only.
flight 66568 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 14 gue
Hi Julien,
On 07/14/2016 11:46 AM, Julien Grall wrote:
Hi Shanker,
On 14/07/16 17:18, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. I
flight 97298 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 96211
test-amd64-i38
flight 97297 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 94748
test-amd64-i386-
On Thu, Jul 14, 2016 at 01:56:24PM +0100, Ian Jackson wrote:
> osstest service owner writes ("[linux-3.18 test] 97278: regressions - FAIL"):
> > flight 97278 linux-3.18 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/97278/
> >
> > Regressions :-(
> >
> > Tests which did not succ
On 14/07/2016 21:19, mar...@wetwa.re wrote:
> Hello all,
>
> I've been working on enabling passthrough for newer Nvidia cards and
> drivers (GTX 980 specifically) on Xen and I'd like to document my
> findings up to now and ask for assistance. I apologize if this is not
> the correct mailing list, b
flight 97289 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 96188
test-amd64-amd64-xl-qe
flight 97310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97310/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Hello all,
I've been working on enabling passthrough for newer Nvidia cards and
drivers (GTX 980 specifically) on Xen and I'd like to document my
findings up to now and ask for assistance. I apologize if this is not
the correct mailing list, but I thought xen-devel is more suitable since
we a
* Paul Gortmaker wrote:
> [Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On
> 14/07/2016 (Thu 20:39) Ingo Molnar wrote:
>
> >
> > * Paul Gortmaker wrote:
> >
> > > > I'll continue testing with the setup_percpu.c change left out.
> > >
> > > Let me know if you want a res
flight 97285 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 97275
test-armhf-armhf-xl-
[Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On
14/07/2016 (Thu 20:39) Ingo Molnar wrote:
>
> * Paul Gortmaker wrote:
>
> > > I'll continue testing with the setup_percpu.c change left out.
> >
> > Let me know if you want a resend or if you want to just add the
> > asm/de
* Paul Gortmaker wrote:
> > I'll continue testing with the setup_percpu.c change left out.
>
> Let me know if you want a resend or if you want to just add the
> asm/desc.h locally or ...
So I tried the asm/desc.h but saw other build failures - for now gave up.
Can we do this in a separate patc
Hi Julien,
Tested-by: Shanker Donthineni
I have tested this patchset on Qualcomm Technologies QDF2XXX server platform
without any issue.
On 07/14/2016 11:21 AM, Julien Grall wrote:
Hello all,
Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after
the functionality has been reve
On 07/14/2016 11:58 AM, Andrew Cooper wrote:
A subsequent change will introduce C99 bools, at which point 'bool'
becomes a type, and ineligible as a variable name.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
X
On 14/07/16 17:40, Corneliu ZUZU wrote:
On 7/14/2016 1:14 PM, Julien Grall wrote:
On 14/07/16 11:11, Corneliu ZUZU wrote:
On 7/14/2016 12:26 PM, Julien Grall wrote:
On 14/07/16 06:11, Corneliu ZUZU wrote:
On 7/13/2016 10:12 PM, Julien Grall wrote:
Hi Corneliu,
On 13/07/2016 15:18, Cor
flight 97306 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97306/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Hello,
On 14/07/16 17:30, Dirk Behme wrote:
On 14.07.2016 17:55, Stefano Stabellini wrote:
On Thu, 14 Jul 2016, Dirk Behme wrote:
On 14.07.2016 12:38, Stefano Stabellini wrote:
On Thu, 14 Jul 2016, Dirk Behme wrote:
On 13.07.2016 23:03, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-1
On 14/07/2016 17:48, "Ian Jackson" wrote:
>Lars Kurth writes ("Re: [Xen-devel] ACPI builder re-licensing"):
>> I think we should pick a specific version, because the COPYING file in
>>xen.git states - although not very clearly - to pick a specific license
>>with a specific version. Given that l
On 14/07/16 17:18, Dario Faggioli wrote:
> So, during domain destruction, we do:
> cpupool_rm_domain()[ in domain_destroy() ]
> sched_destroy_domain() [ in complete_domain_destroy() ]
>
> Therefore, there's a window during which, from the
> scheduler's point of view, a domain stilsts outside
At 16:58 +0100 on 14 Jul (1468515536), Andrew Cooper wrote:
> and switch bool_t to being of type _Bool rather than char.
>
> Using bool_t as char causes several subtle problems; first that a bool_t
> actually has more than two values, and that (bool_t)0x100 actually has the
> value 0 rather than t
Lars Kurth writes ("Re: [Xen-devel] ACPI builder re-licensing"):
> I think we should pick a specific version, because the COPYING file in
> xen.git states - although not very clearly - to pick a specific license with
> a specific version. Given that libxc/libxl is intended to be LGPL 2.1, we
> s
Hi Shanker,
On 14/07/16 17:18, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations fo
On 7/14/2016 1:14 PM, Julien Grall wrote:
On 14/07/16 11:11, Corneliu ZUZU wrote:
On 7/14/2016 12:26 PM, Julien Grall wrote:
On 14/07/16 06:11, Corneliu ZUZU wrote:
On 7/13/2016 10:12 PM, Julien Grall wrote:
Hi Corneliu,
On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros be
> On 13 Jul 2016, at 19:19, Boris Ostrovsky wrote:
>
> On 07/13/2016 10:30 AM, Lars Kurth wrote:
>>
>>
>>> OTOH, we can at least
>>> review the patch first here on xen-devel without bothering people from
>>> that list with revisions. So yes, I will.
>
>
> Which LGPL version are we using?
>
On 14.07.2016 17:55, Stefano Stabellini wrote:
On Thu, 14 Jul 2016, Dirk Behme wrote:
On 14.07.2016 12:38, Stefano Stabellini wrote:
On Thu, 14 Jul 2016, Dirk Behme wrote:
On 13.07.2016 23:03, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-13 11:56:30)
On 13.07.2016 20:43, Stefano Stab
Hi Shanker,
Can you please try to thread properly your series, and re-number it with
the correct amount of patch if some have been applied.
It will avoid people to wondering if they missed some e-mails.
On 14/07/16 17:18, Shanker Donthineni wrote:
This patch adds the generic implementation o
On 14/07/16 17:12, Julien Grall wrote:
> Hi Andrew,
>
> On 14/07/16 16:58, Andrew Cooper wrote:
>> and switch bool_t to being of type _Bool rather than char.
>>
>> Using bool_t as char causes several subtle problems; first that a bool_t
>> actually has more than two values, and that (bool_t)0x100 a
Hi,
On 14/07/16 17:22, Julien Grall wrote:
This reverts commit f91c84edebe67296e4051af055dbf0adafb13a37. SPI
routing for ACPI support will be added in a follow-up patch.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
I made a typo in Stefano's address mail. This should be
ssta
The callback set_irq_properties will configure the GIC for a specific
IRQ with the type and the priority.
In a follow-up patch, Xen will configure the type and the priority at
different stage of the routing. So split it in 2 separate callbacks.
At the same time, move the ASSERT to check the valid
This reverts commit f91c84edebe67296e4051af055dbf0adafb13a37. SPI
routing for ACPI support will be added in a follow-up patch.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/vgic.c | 15 ---
1
Changing the value of Int_config is UNPREDICTABLE when the corresponding
interrupt is not disabled.
The driver is assuming the interrupt will be disabled by the caller of
gic_set_irq_type. Add an ASSERT to ensure it.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v
It is not possible to know which IRQs will be used by DOM0 when ACPI is
inuse. The approach implemented by this patch, will route all unused
IRQs to DOM0 before it has booted.
The number of IRQs routed is based on the maximum SPIs supported by the
hardware (up to ~1000). However, some of them migh
The comment was not correctly indented. Also the preferred name for the
initial domain is "hardware domain" and not "dom0, so replace it.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
A follow-up patch will not store the type in desc->arch.type. Also, the
callback prototype is more logical.
Signed-off-by: Julien Grall
---
Changes in v2:
- gic_set_irq_type has been dropped by mistake in
gic_route_irq_to_xen. Re-add it!
---
xen/arch/arm/gic-v2.c | 3 +-
The code to set the IRQ affinity is duplicated: once in
gicv{2,3}_set_properties and the other is gicv{2,3}_irq_set_affinity.
Remove the code from gicv{2,3}_set_properties and call directly the
affinity set helper from the common code.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Hello all,
Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after
the functionality has been reverted in Xen 4.7 by commit 909bd14.
In the previous approach, the SPIs was routed when DOM0 was writing into
ISENABLER. However, this has resulted to deadlock (see more details in [1])
as
The function route_irq_to_guest mandates the IRQ type, stored in
desc->arch.type, to be valid. However, in case of ACPI, these
information is not part of the static tables. Therefore Xen needs to
rely on DOM0 to provide a valid type based on the firmware tables.
A new helper, irq_type_set_by_domai
The affinity of a guest IRQ is set every time the guest enable it (see
vgic_enable_irqs).
It is not necessary to set the affinity when the IRQ is routed to the
guest because Xen will never receive the IRQ until it hass been enabled
by the guest.
To keep gic_route_irq_to_{xen,guest} behaving the s
This patch adds the generic implementation of binary search algorithm
whcih is copied from Linux kernel. Only coding style changes to match
the general XEN coding style. No functional changes.
Signed-off-by: Shanker Donthineni
---
xen/common/Makefile | 1 +
xen/common/bsearch.c | 52
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations for finding a matching handler. Now
it is time for us to chang
The number of mmio handlers are limited to a compile time macro
MAX_IO_HANDLER which is 16. This number is not at all sufficient
to support per CPU distributor regions. Either it needs to be
increased to a bigger number, at least CONFIG_NR_CPUS+16, or
allocate a separate memory for mmio handlers dy
So, during domain destruction, we do:
cpupool_rm_domain()[ in domain_destroy() ]
sched_destroy_domain() [ in complete_domain_destroy() ]
Therefore, there's a window during which, from the
scheduler's point of view, a domain stilsts outside
of any cpupool.
In fact, cpupool_rm_domain() does d
Compute the number of mmio handlers that are required for vGICv3 and
vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment
this variable number of mmio handers to a fixed number MAX_IO_HANDLER
and pass it to domain_io_init() to allocate enough memory.
New code path:
domain_vgic_regis
If the domain is already where we want it to go,
there's not much to do indeed.
Signed-off-by: Dario Faggioli
---
Cc: Juergen Gross
---
xen/common/cpupool.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 5dacc61..9998394 100644
--- a/
Hi everyone,
Version 2, with only patch 1 changed to follow Andrew's suggestion of directly
moving the cpupool_*_domain() functions into the sched_*_domain() functions.
That required changing the signature of sched_init_domain(), but I think the
final state of the code is indeed more robust.
Tha
Hi Andrew,
On 14/07/16 16:58, Andrew Cooper wrote:
and switch bool_t to being of type _Bool rather than char.
Using bool_t as char causes several subtle problems; first that a bool_t
actually has more than two values, and that (bool_t)0x100 actually has the
value 0 rather than the expected 1, d
and switch bool_t to being of type _Bool rather than char.
Using bool_t as char causes several subtle problems; first that a bool_t
actually has more than two values, and that (bool_t)0x100 actually has the
value 0 rather than the expected 1, due to truncation.
Making this change reveals two bugs
A subsequent change will introduce C99 bools, at which point 'bool'
becomes a type, and ineligible as a variable name.
Signed-off-by: Andrew Cooper
---
CC: Daniel De Graaf
---
xen/xsm/flask/ss/conditional.c | 6 +++---
xen/xsm/flask/ss/conditional.h | 2 +-
2 files changed, 4 insertions(+), 4 d
On Tue, Jul 12, 2016 at 05:07:35PM +0100, Andrew Cooper wrote:
> On 12/07/16 16:36, Anthony PERARD wrote:
> > On Tue, Jul 12, 2016 at 04:09:59PM +0100, Andrew Cooper wrote:
> >> On 12/07/16 15:42, Anthony PERARD wrote:
> >>> +#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> >>> +#define __XEN_PUB
On Thu, 14 Jul 2016, Dirk Behme wrote:
> On 14.07.2016 12:38, Stefano Stabellini wrote:
> > On Thu, 14 Jul 2016, Dirk Behme wrote:
> > > On 13.07.2016 23:03, Michael Turquette wrote:
> > > > Quoting Dirk Behme (2016-07-13 11:56:30)
> > > > > On 13.07.2016 20:43, Stefano Stabellini wrote:
> > > > >
Hi,
I've been investigating why OVMF is very slow in a Xen guest on an AMD
host. This, I think, is the current failure that osstest is having.
I've only look at a specific part of OVMF where the slowdown is very
obvious on AMD vs Intel, the decompression.
This is what I get on AMD, via the Xen
On Wed, 22 Jun 2016, Julien Grall wrote:
> The ARM erratum applies to certain revisions of Cortex-A57. The
> processor may report a Stage 2 translation fault as the result of
> Stage 1 fault for load crossing a page boundary when there is a
> permission fault or device memory fault at stage 1 and a
On Thu, 14 Jul 2016, Julien Grall wrote:
> On 14/07/16 16:27, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 591de3c..0edc2cc 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
>
Hi Quan,
thanks for CC'ing me. sstabell...@kernel.org is the right address to
reach me now.
I am also CC'ing Anthony Perard who is Xen co-maintainer in QEMU.
Cheers,
Stefano
On Wed, 13 Jul 2016, Xu, Quan wrote:
> Emil, Thanks for your effort ( today I just come back to return my laptop).
>
>
On 14/07/16 16:27, Stefano Stabellini wrote:
On Wed, 22 Jun 2016, Julien Grall wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 591de3c..0edc2cc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2383,13 +2383,28 @@ static inline paddr_t get_faulting_ipa(vadd
Hi Stefano/Juilen
On 07/14/2016 09:18 AM, Stefano Stabellini wrote:
On Mon, 27 Jun 2016, Shanker Donthineni wrote:
The function acpi_table_parse_madt() does the same functionality as
function acpi_parse_entries() expect it takes a few arguments.
Signed-off-by: Shanker Donthineni
I committed
Hi Stefano,
On 14/07/16 16:06, Stefano Stabellini wrote:
On Wed, 22 Jun 2016, Julien Grall wrote:
-if (handle_mmio(&info))
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_mmio(&info) )
+{
+advance_pc(regs, hsr);
+return;
+
On 14/07/16 16:28, Stefano Stabellini wrote:
On Thu, 14 Jul 2016, Julien Grall wrote:
Hi Stefano,
On 14/07/16 16:06, Stefano Stabellini wrote:
On Wed, 22 Jun 2016, Julien Grall wrote:
-if (handle_mmio(&info))
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_m
On Thu, 14 Jul 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 14/07/16 16:06, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > -if (handle_mmio(&info))
> > > -{
> > > -advance_pc(regs, hsr);
> > > -return;
> > > +if ( handle_mmio(&info) )
On Wed, 22 Jun 2016, Julien Grall wrote:
> Translating a VA to a IPA is expensive. Currently, Xen is assuming that
> HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened
> during a translation table walk of a first stage translation (i.e S1PTW
> is set).
>
> However, based on t
[Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On
14/07/2016 (Thu 15:04) Ingo Molnar wrote:
>
> * Paul Gortmaker wrote:
>
> > To that end, I have done allmodconfig, allyesconfig and allnoconfig
> > for both 32 bit and 64 bit x86 with these changes on the linux-next
> > from
On 14/07/16 15:46, Anshul Makkar wrote:
> Access to setpodtarget and getpodtarget is required by dom0 to set the balloon
> targets for domU. The patch gives source domain (dom0) access to set
> this target for domU and resolve the following permission denied erro
> message during ballooning :
> avc
On 14/07/16 15:18, Daniel De Graaf wrote:
> This makes the buffers function parameters instead of globals, in
> preparation for adding alternate locations for the policy.
>
> Signed-off-by: Daniel De Graaf
> Reviewed-by: Jan Beulich
> ---
Reviewed and committed both patches.
~Andrew
__
On Wed, 22 Jun 2016, Julien Grall wrote:
> The function do_trap_data_abort_guest assumes that a stage-2 data abort
> can only be taken for a translation fault or permission fault today.
>
> Whilst this is true today, it might not be in the future. Rather than
> emulating the MMIO for any fault oth
On 14/07/16 15:54, Dario Faggioli wrote:
> On Thu, 2016-07-14 at 10:37 +0100, Andrew Cooper wrote:
>> On 14/07/16 07:41, Dario Faggioli wrote:
>>> So, during domain destruction, we do:
>>> cpupool_rm_domain()[ in domain_destroy() ]
>>> sched_destroy_domain() [ in complete_domain_destroy() ]
>
On Thu, 2016-07-14 at 10:37 +0100, Andrew Cooper wrote:
> On 14/07/16 07:41, Dario Faggioli wrote:
> >
> > So, during domain destruction, we do:
> > cpupool_rm_domain()[ in domain_destroy() ]
> > sched_destroy_domain() [ in complete_domain_destroy() ]
> >
> > Therefore, there's a window dur
Access to setpodtarget and getpodtarget is required by dom0 to set the balloon
targets for domU. The patch gives source domain (dom0) access to set
this target for domU and resolve the following permission denied erro
message during ballooning :
avc: denied { setpodtarget } for domid=0 target=9
s
flight 97302 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97302/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 14 July 2016 14:21
> To: Owen Smith; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] Add optional ACPI device for Windows
> Continuum
>
> On 13/07/16 10:16, Owen Smith wrote:
> > Window
Hi Stefano,
On 14/07/16 15:34, Stefano Stabellini wrote:
On Wed, 22 Jun 2016, Julien Grall wrote:
Currently, Xen is reading the MIDR everytime it has to check whether
the processor is affected by the erratum 766422.
This could take advantage of the new capability bitfields to detect
whether th
On Wed, 22 Jun 2016, Julien Grall wrote:
> Currently, Xen is reading the MIDR everytime it has to check whether
> the processor is affected by the erratum 766422.
>
> This could take advantage of the new capability bitfields to detect
> whether the processor is affected at boot time.
>
> With thi
On 14/07/16 15:18, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor. The policy provided by the b
On 14/07/16 15:18, Daniel De Graaf wrote:
> This makes the buffers function parameters instead of globals, in
> preparation for adding alternate locations for the policy.
>
> Signed-off-by: Daniel De Graaf
> Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor. The policy provided by the bootloader, if present, will
override the built-in
This makes the buffers function parameters instead of globals, in
preparation for adding alternate locations for the policy.
Signed-off-by: Daniel De Graaf
Reviewed-by: Jan Beulich
---
Changes since v5:
- Adjusted __init annotation placement
- Removed unneeded cast to char*
xen/include/xsm/
flight 97286 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 97003
build-armhf-libvirt
On Mon, 27 Jun 2016, Shanker Donthineni wrote:
> The function acpi_table_parse_madt() does the same functionality as
> function acpi_parse_entries() expect it takes a few arguments.
>
> Signed-off-by: Shanker Donthineni
I committed patches 1 to 7
> xen/arch/arm/gic-v3.c | 27 ++---
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defined in GICC
subtable. The GIC CPU subtable entry h
On Wed, 22 Jun 2016, Julien Grall wrote:
> Workarounds may require to execute a different path when the platform
> is affected by the associated erratum. Furthermore, this may need to
> be called in the common code.
>
> To avoid too much intrusion/overhead, the workaround helpers need to
> be a no
This run is configured for baseline tests only.
flight 66565 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66565/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-build
On Wed, 13 Jul 2016, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > On 2016年07月12日 22:50, Wei Liu wrote:
> >
On Thu, 14 Jul 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 14/07/16 12:12, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > The fault status we care are all the form xx where xx is the lookup
> >
> > ^ in the form of
> >
> > >
On 13/07/16 22:43, Boris Ostrovsky wrote:
> On 07/13/2016 05:06 PM, Andrew Cooper wrote:
>> On 13/07/2016 21:57, Boris Ostrovsky wrote:
>>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
On 13/07/2016 21:17, Boris Ostrovsky wrote:
> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>> On 13/0
On 13/07/16 10:16, Owen Smith wrote:
> Windows 10 supports a specific ACPI device for handling the
> switch between tablet mode and desktop mode. The meer existance
> of this device is the mimimum to allow tablet/desktop mode to
> be switched.
> Tablet mode referes to the "undocked" state where all
1 - 100 of 165 matches
Mail list logo
