Support ARM SiP (Silicon Provider) services.
- Import arm-smccc.h from Linux Kernel
ca122fe376fc ("Merge tag 'arc-4.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc")
- Introudce a new callback function in platform_desc
- Add do_trap_hvccc to handle non xen specific hype
flight 116915 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
On Tue, Nov 28, 2017 at 03:08:46PM +, Paul Durrant wrote:
>A subsequent patch will introduce a new scheme to allow an emulator to
>map ioreq server pages directly from Xen rather than the guest P2M.
>
>This patch lays the groundwork for that change by deferring mapping of
>gfns until their valu
flight 116904 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116904/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116683
test-armhf-armhf-libvirt-xsm 14 sav
On Wed, 6 Dec 2017, Oleksandr Tyshchenko wrote:
> >> +perf->platform_limit = platform_limit;
> >> +perf->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >> +perf->domain_info.domain = cpumask_first(mask);
> >> +perf->domain_info.num_processors = cpumask_weight(mask);
> >> +
> >> +/* It
flight 116894 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116894/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-amd64-amd64-xl-qemut-win7-amd64 16 gues
On Wed, 6 Dec 2017, Jan Beulich wrote:
> >>> On 05.12.17 at 21:48, wrote:
> > You are right. We need to define a new struct for internal usage, for
> > example:
> >
> > struct xen_processor_performance_internal {
> > uint32_t flags; /* flag for Px sub info type */
> > uint32_t platfor
Hi,
On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote:
On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich wrote:
On 25.07.17 at 19:26, wrote:
The presence of this flag lets us know that the guest domain has statically
assigned devices which will most likely be used for passthrough
and as the resul
Hi,
Answering to myself.
On 12/04/2017 02:30 PM, Julien Grall wrote:
On 01/12/17 22:58, Stefano Stabellini wrote:
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
= Xen command forwarding =
In the code below, it looks like Xen is forwarding everything to OP-TEE.
Are there some commands Xen shoul
Hi Stuart,
On 12/05/2017 03:36 PM, Stuart Yoder wrote:
There are limit on pCPUs, though. But this is not a problem, because
XEN scheduler will decide which guest will access OP-TEE right now.
OP-TEE don't have own scheduler at all, by the way. It is scheduled
by normal world.
Do you mind to
flight 116902 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116902/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116849
test-armhf-armhf-libvirt-raw 13 saveresto
flight 116891 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116891/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116832
test-armhf-armhf-libvirt 14 save
From: Joe Perches
Date: Tue, 5 Dec 2017 22:40:25 -0800
> Using a period after a newline causes bad output.
>
> Signed-off-by: Joe Perches
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
They are straight aliases of the more common X86EMUL_* constants. While
adjusting these, fix the case indentation where appropriate.
No functional change, confirmed by diff'ing the compiled binary.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch
Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators back
for MSR accesses", returnning X86EMUL_EXCEPTION has pushed the exception
generation to the top of the call tree.
Using hvm_inject_hw_exception() and returning X86EMUL_EXCEPTION causes a
double #GP injection, which combines
Hi Jan.
On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich wrote:
On 25.07.17 at 19:26, wrote:
>> The presence of this flag lets us know that the guest domain has statically
>> assigned devices which will most likely be used for passthrough
>> and as the result the IOMMU is expected to be used for
On 06/12/17 16:38, Jan Beulich wrote:
> As of commit 91f85280b9 ("x86: fix GS-base-dirty determination") the
> USER part of it isn't really appropriate anymore.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-d
On 06/12/17 16:37, Jan Beulich wrote:
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -172,6 +173,24 @@ static inline unsigned long rdgsbase(voi
> return base;
> }
>
Hi, Jan.
On Wed, Dec 6, 2017 at 7:01 PM, Jan Beulich wrote:
On 25.07.17 at 19:26, wrote:
>> From: Oleksandr Tyshchenko
>>
>> The hardware domains require IOMMU to be used in the most cases and
>> a decision to use it is made at hardware domain construction time.
>> But, it is not the best
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/intel.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index ac932e5..d3145c0 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -15,8 +15,6 @@
Hi,
On 26/10/17 01:37, Stefano Stabellini wrote:
> On Thu, 19 Oct 2017, Andre Przywara wrote:
>> Currently gic.c holds code to handle hardware IRQs as well as code to
>> bridge VGIC requests to the GIC virtualization hardware.
>
> That is true, however, I don't necessarely see "the code to bridge
Hi,
On 26/10/17 01:20, Stefano Stabellini wrote:
> On Thu, 19 Oct 2017, Andre Przywara wrote:
>> gic_remove_from_lr_pending() was not only misnamed, it also had the wrong
>> abstraction, as it should not live in gic.c.
>> Move it into vgic.c and vgic.h, where it belongs, and rename it on the
>> wa
Hi,
On 10/11/17 16:42, Andre Przywara wrote:
> Hi,
>
> On 26/10/17 01:14, Stefano Stabellini wrote:
>> On Thu, 19 Oct 2017, Andre Przywara wrote:
>>> gic_clear_pending_irqs() was not only misnamed, but also misplaced, as
>>> a function solely dealing with the GIC emulation should not live in gic.
This is based on make-flight, with the added all_host_os=centos runvar,
and without test that can not be run.
Anything based on the recipe "test-debian" or "test-pair" is remove, as
they require xen-tools. There is no XSM tests as the CentOS packages is
built without. There is no build jobs as the
On host running with systemd as init, doing `ssh host reboot` will
result in ssh returning an error.
This patch works around by not waiting for the reboot command to return.
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 40a5c5a..c82ba96 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1949,8 +1949,8 @@ sub make_q
This also select a different xen installation script.
Signed-off-by: Anthony PERARD
---
sg-run-job | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index f6e8340..b324101 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -25,8 +25,9 @@ readc
Ajust configuration of xenconsoled and libvirtd.
Signed-off-by: Anthony PERARD
---
ts-centos-xen-pkg-install | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ts-centos-xen-pkg-install b/ts-centos-xen-pkg-install
index e10456d..0327b72 100755
--- a/ts-centos-xen-pkg-install
+++ b/t
Install candidate packages that have been built by CBS, the CentOS
Community Build Service.
Signed-off-by: Anthony PERARD
---
ts-centos-xen-pkg-install | 79 +++
1 file changed, 79 insertions(+)
create mode 100755 ts-centos-xen-pkg-install
diff --git
Signed-off-by: Anthony PERARD
---
ts-centos-xen-pkg-install | 22 ++
1 file changed, 22 insertions(+)
diff --git a/ts-centos-xen-pkg-install b/ts-centos-xen-pkg-install
index 0327b72..9a4dcdd 100755
--- a/ts-centos-xen-pkg-install
+++ b/ts-centos-xen-pkg-install
@@ -82,8 +82,
This function will be use later to install CentOS on a host.
Signed-off-by: Anthony PERARD
---
Osstest/CentOS.pm | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Osstest/CentOS.pm
diff --git a/Osstest/CentOS.pm b/Osstest/CentOS.pm
ne
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 13e4360..b0e21bf 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2818,7 +2818,8 @@ sub guest_ed
The location for new certificates is different, and
update-ca-certificates is Debian specific.
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index b0e21bf
This emulate the osstest-confirm-booted service that is done on Debian.
In order to have the service been started last:
- it is made dependent on multi-user.target which is the default target on
systemd.
- it is part of osstest.target which depend on multi-user.target.
- the osstest.target is set
Signed-off-by: Anthony PERARD
---
ts-centos-host-install | 154 +
1 file changed, 154 insertions(+)
create mode 100755 ts-centos-host-install
diff --git a/ts-centos-host-install b/ts-centos-host-install
new file mode 100755
index 000..943002d
Signed-off-by: Anthony PERARD
---
Osstest/CentOS.pm | 215 ++
1 file changed, 215 insertions(+)
diff --git a/Osstest/CentOS.pm b/Osstest/CentOS.pm
index 33479b1..dbba354 100644
--- a/Osstest/CentOS.pm
+++ b/Osstest/CentOS.pm
@@ -28,13 +28,22 @@
Hi Jan,
On 12/06/2017 03:15 PM, Jan Beulich wrote:
On 06.12.17 at 13:58, wrote:
On 12/06/2017 12:28 PM, George Dunlap wrote:
2. It sounds like rather than using PoD, you could use the
"misconfigured p2m table" technique that x86 uses: set bits in the p2m
entry which cause a specific kind of H
e.g. If the file to be edited is only accessible to the root user,
target_getfile() would not work.
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index c9dada3..65324fb
Hi,
This patch series teach osstest how to install CentOS 7 on a host and how to
install Xen via packages that have been built in the CentOS Community Build
Service (or CBS).
For now, this is only usefull in standalone or to start ad-hoc flight, as there
is nothing to build Xen.
It is based on R
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 65324fb..13e4360 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -530,6 +530,8 @@ sub package_install_cmd ($;$)
This fix the error bellow, when the runvar exist:
can't read "runvarinfo()": no such element in array
while executing
"set val $runvarinfo($val)"
invoked from within
"osstestdb eval {
SELECT val FROM runvars
WHERE flight = $flight
AND job = $job
AND na
On 12/06/2017 12:58 PM, Julien Grall wrote:
> Hi George,
>
> On 12/06/2017 12:28 PM, George Dunlap wrote:
>> On 12/05/2017 06:39 PM, Julien Grall wrote:
>>> Hi all,
>>>
>>> Even though it is an Arm failure, I have CCed x86 folks to get feedback
>>> on the approach. I have a WIP branch I could shar
Hi Andrew,
On 12/06/2017 03:08 PM, Andrew Cooper wrote:
On 06/12/17 13:04, Julien Grall wrote:
Hi Jan,
On 12/06/2017 12:58 PM, Jan Beulich wrote:
On 06.12.17 at 12:47, wrote:
On 12/06/2017 11:45 AM, Jan Beulich wrote:
On 06.12.17 at 10:47, wrote:
I guess I have been CCed because you woul
>>> On 06.12.17 at 17:40, wrote:
> On 06/12/17 16:21, Jan Beulich wrote:
>> There's no need for
>> - advancing the handles and at the same time using
>> __copy_{from,to}_guest_offset(),
>> - an "out" label,
>> - local variables "done" and (function scope) "rc".
>>
>> Signed-off-by: Jan Beulich
On 06/12/17 16:27, Jan Beulich wrote:
> On input "c" being 0xff should already have the effect of bailing early
> (due to the isprint()), but let's rather make this explicit. Also
> convert the BUG_ON() to an ASSERT() (nothing fatal happens in the
> function if this is violated), at the same time e
>>> On 25.07.17 at 19:26, wrote:
> From: Oleksandr Tyshchenko
>
> The hardware domains require IOMMU to be used in the most cases and
> a decision to use it is made at hardware domain construction time.
> But, it is not the best moment for the non-shared IOMMUs due to
> the necessity of retrievi
On 06/12/17 16:28, Jan Beulich wrote:
> Perhaps there once was a plan to have a flush type requiring this, but
> the current SDM has no mention of such and all callers pass zero anyway.
>
> Take the opportunity and also change involved types to uint64_t.
>
> Signed-off-by: Jan Beulich
Reviewed-by
>>> On 25.07.17 at 19:26, wrote:
> The presence of this flag lets us know that the guest domain has statically
> assigned devices which will most likely be used for passthrough
> and as the result the IOMMU is expected to be used for this domain.
>
> Taking into the account this hint when dealing
On 06/12/17 16:21, Jan Beulich wrote:
> There's no need for
> - advancing the handles and at the same time using
> __copy_{from,to}_guest_offset(),
> - an "out" label,
> - local variables "done" and (function scope) "rc".
>
> Signed-off-by: Jan Beulich
These changes do mean that start is no lon
>>> On 06.12.17 at 17:32, wrote:
> On 06/12/17 16:21, Jan Beulich wrote:
>> As its name says, it handles a single GMFN only anyway. Note that ARM
>> needs no adjustment, as it doesn't handle the two types at all.
>>
>> Also take the opportunity and clean up the handling of XENMAPSPACE_gmfn
>> a li
On 12/05/2017 01:29 PM, Stefano Stabellini wrote:
> On Tue, 5 Dec 2017, Dan Carpenter wrote:
>> bedata->ref can't be less than zero because it's unsigned. This affects
>> certain error paths in probe. We first set ->ref = -1 and then we set
>> it to a valid value later.
>>
>> Fixes: 219681909913
On 06/12/17 16:21, Jan Beulich wrote:
> As its name says, it handles a single GMFN only anyway. Note that ARM
> needs no adjustment, as it doesn't handle the two types at all.
>
> Also take the opportunity and clean up the handling of XENMAPSPACE_gmfn
> a little: There's no point in going through "
On 12/05/2017 01:26 PM, Stefano Stabellini wrote:
> On Tue, 5 Dec 2017, Dan Carpenter wrote:
>> Smatch complains that "len" is uninitialized if xenbus_read() fails so
>> let's add some error handling.
>>
>> Signed-off-by: Dan Carpenter
> Reviewed-by: Stefano Stabellini
Applied to for-linus-4.15.
As of commit 91f85280b9 ("x86: fix GS-base-dirty determination") the
USER part of it isn't really appropriate anymore.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1276,7 +1276,7 @@ static DEFINE_PER_CPU(unsigned int, dirt
#define DIRTY_FS 0x0
Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a double
SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time for
a shadow GS update alone on my Haswell (and we have indications of
good performance improvements by this on Skylake too), while the win is
even higher when e
On 06/12/17 16:20, Jan Beulich wrote:
> It goes all silent, leaving open what has actually caused the crash.
> Use domain_crash() instead, which leaves a log message before calling
> domain_shutdown(..., SHUTDOWN_crash).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
On 06/12/17 16:19, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
1: improve MSR_SHADOW_GS accesses
2: rename DIRTY_GS_BASE_USER
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Perhaps there once was a plan to have a flush type requiring this, but
the current SDM has no mention of such and all callers pass zero anyway.
Take the opportunity and also change involved types to uint64_t.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx
On input "c" being 0xff should already have the effect of bailing early
(due to the isprint()), but let's rather make this explicit. Also
convert the BUG_ON() to an ASSERT() (nothing fatal happens in the
function if this is violated), at the same time extending what is being
checked.
Signed-off-by
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 06 December 2017 09:02
> To: Paul Durrant
> Cc: xen-de...@lists.xen.org; Tim (Xen.org) ; Stefano
> Stabellini ; Konrad Rzeszutek Wilk
> ; Jan Beulich ; George
> Dunlap ; Andrew Cooper
> ; Wei Liu ; Ian Jackson
>
> S
There's no need for
- advancing the handles and at the same time using
__copy_{from,to}_guest_offset(),
- an "out" label,
- local variables "done" and (function scope) "rc".
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -820,65 +820,37 @@ static int xenmem_a
As its name says, it handles a single GMFN only anyway. Note that ARM
needs no adjustment, as it doesn't handle the two types at all.
Also take the opportunity and clean up the handling of XENMAPSPACE_gmfn
a little: There's no point in going through "idx" when capturing the MFN.
Signed-off-by: Ja
It goes all silent, leaving open what has actually caused the crash.
Use domain_crash() instead, which leaves a log message before calling
domain_shutdown(..., SHUTDOWN_crash).
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1546,7 +1546,7 @@ int offlin
Signed-off-by: Jan Beulich
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -42,19 +42,20 @@ bool __mfn_valid(unsigned long mfn)
/* Sets all bits from the most-significant 1-bit down to the LSB */
static u64 __init fill_mask(u64 mask)
{
-while (mask & (mask + 1))
-mask
Instead of giving, to subsequent code, the appearance of there not
having been any "info" data provided, adjust the conditional guarding
SR-IOV handling.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -629,10 +629,7 @@ int pci_add_device(u16
None of the models MISC_ENABLE MSR access is excluded for support 64-bit
mode - drop the conditional from early_init_intel(). Also convert
pointless rdmsr_safe() elsewhere to rdmsrl().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -285,31 +285,29 @@
On Wed, Dec 06, 2017 at 03:04:11PM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 06 December 2017 07:50
>> To: xen-de...@lists.xen.org
>> Cc: Chao Gao ; Paul Durrant
>> ; Tim (Xen.org) ; Stefano Stabellini
>> ; Konrad Rzeszutek Wilk
flight 116876 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
115643
test-amd64-am
On 06/12/17 15:31, Jan Beulich wrote:
> There is no need to hold the global domctl lock across domain_kill() -
> the domain lock is fully sufficient here, and parallel cleanup after
> multiple domains performs quite a bit better this way.
>
> Signed-off-by: Jan Beulich
This is clearer. Reviewed-
On Wed, Dec 06, 2017 at 02:44:52PM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 06 December 2017 07:50
>> To: xen-de...@lists.xen.org
>> Cc: Chao Gao ; Andrew Cooper
>> ; Jan Beulich ; Paul
>> Durrant
>> Subject: [RFC Patch v4 1/8]
There is no need to hold the global domctl lock across domain_kill() -
the domain lock is fully sufficient here, and parallel cleanup after
multiple domains performs quite a bit better this way.
Signed-off-by: Jan Beulich
---
Changes since RFC: Comment added.
---
Obviously other domctl-s could be
flight 116890 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm broken in 116862
build-armhf-xsm 5 h
On 06/12/17 13:04, Julien Grall wrote:
> Hi Jan,
>
> On 12/06/2017 12:58 PM, Jan Beulich wrote:
> On 06.12.17 at 12:47, wrote:
>>> On 12/06/2017 11:45 AM, Jan Beulich wrote:
>>> On 06.12.17 at 10:47, wrote:
> I guess I have been CCed because you would like this patch is
> fixing t
On 12/06/2017 03:24 PM, George Dunlap wrote:
On 12/06/2017 03:19 PM, Julien Grall wrote:
Hi Konrad,
On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
.snip..
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to
det
On 12/06/2017 03:19 PM, Julien Grall wrote:
> Hi Konrad,
>
> On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
>> .snip..
>>> The suggested policy is based on the KVM one:
>>> - If we trap a S/W instructions, we enable VM trapping (e.g
>>> HCR_EL2.TVM) to
>>> detect cache being turned on/of
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 06 December 2017 07:50
> To: xen-de...@lists.xen.org
> Cc: Chao Gao ; Paul Durrant
> ; Tim (Xen.org) ; Stefano Stabellini
> ; Konrad Rzeszutek Wilk
> ; Jan Beulich ; George
> Dunlap ; Andrew Cooper
> ; Wei Liu ; Ian J
Hi Konrad,
On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
.snip..
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to
detect cache being turned on/off, and do a full clean.
- We flush the caches on both
>>> On 06.12.17 at 13:58, wrote:
> On 12/06/2017 12:28 PM, George Dunlap wrote:
>> 2. It sounds like rather than using PoD, you could use the
>> "misconfigured p2m table" technique that x86 uses: set bits in the p2m
>> entry which cause a specific kind of HAP fault when accessed. The fault
>> han
.snip..
> The suggested policy is based on the KVM one:
> - If we trap a S/W instructions, we enable VM trapping (e.g
> HCR_EL2.TVM) to
> detect cache being turned on/off, and do a full clean.
> - We flush the caches on both caches being turned on and off.
> - Once the caches are
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 06 December 2017 07:50
> To: xen-de...@lists.xen.org
> Cc: Chao Gao ; Andrew Cooper
> ; Jan Beulich ; Paul
> Durrant
> Subject: [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static
> functions
>
> It is
From: Julien Grall
When system registers are not enabled, all the access to them will trap
in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only
on success. As the rest of the code (e.g gicv3_hyp_init) relies on
system register, it is better to bail out directly.
This will save
flight 116916 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116916/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Hi Jan,
On 12/06/2017 12:58 PM, Jan Beulich wrote:
On 06.12.17 at 12:47, wrote:
On 12/06/2017 11:45 AM, Jan Beulich wrote:
On 06.12.17 at 10:47, wrote:
I guess I have been CCed because you would like this patch is fixing the
regression you mentioned on IRC?
Yes, but first of all we need t
On 12/06/2017 12:58 PM, Julien Grall wrote:
Hi George,
On 12/06/2017 12:28 PM, George Dunlap wrote:
On 12/05/2017 06:39 PM, Julien Grall wrote:
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback
on the approach. I have a WIP branch I could share if that interest
Hi George,
On 12/06/2017 12:28 PM, George Dunlap wrote:
On 12/05/2017 06:39 PM, Julien Grall wrote:
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback
on the approach. I have a WIP branch I could share if that interest people.
Few months ago, we noticed an heisenb
>>> On 06.12.17 at 12:47, wrote:
> On 12/06/2017 11:45 AM, Jan Beulich wrote:
> On 06.12.17 at 10:47, wrote:
>>> I guess I have been CCed because you would like this patch is fixing the
>>> regression you mentioned on IRC?
>>
>> Yes, but first of all we need to see whether the issue goes awa
On 12/05/2017 06:39 PM, Julien Grall wrote:
> Hi all,
>
> Even though it is an Arm failure, I have CCed x86 folks to get feedback
> on the approach. I have a WIP branch I could share if that interest people.
>
> Few months ago, we noticed an heisenbug on jobs run by osstest on the
> cubietrucks (
Hi Stefano,
On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
On Thu, 23 Nov 2017, Julien Grall wrote:
Hi Andrew,
On 23/11/17 18:49, Andrew Cooper wrote:
On 23/11/17 18:32, Julien Grall wrote:
This new function will be used in a follow-up patch to copy data to the
guest
using the IPA (aka gu
Hi Stefano,
On 12/06/2017 01:22 AM, Stefano Stabellini wrote:
On Thu, 23 Nov 2017, Julien Grall wrote:
The only differences between copy_to_guest and access_guest_memory_by_ipa are:
- The latter does not support copying data crossing page boundary
- The former is copying from/to guest
On Thu, Nov 30, 2017 at 10:22:57PM +0100, Daniel Kiper wrote:
[...]
> Understood! I will apply this patch next week.
Pushed!
Thanks,
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
Hi Jan,
On 12/06/2017 09:15 AM, Jan Beulich wrote:
On 05.12.17 at 19:39, wrote:
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
- We flush the caches
flight 116909 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116909/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 289adc1c56562d88e50b04245cd2027df8813bf4
baseline version:
xen 4cd0
On 06/12/17 12:50, Julien Grall wrote:
> Hi,
>
> On 12/06/2017 11:47 AM, Roger Pau Monné wrote:
>> On Wed, Dec 06, 2017 at 12:22:00PM +0100, Juergen Gross wrote:
>>> On 06/12/17 10:53, Julien Grall wrote:
Hi Juergen,
On 12/05/2017 04:19 PM, Juergen Gross wrote:
> On 05/12/17 16:
Hi,
On 12/06/2017 11:47 AM, Roger Pau Monné wrote:
On Wed, Dec 06, 2017 at 12:22:00PM +0100, Juergen Gross wrote:
On 06/12/17 10:53, Julien Grall wrote:
Hi Juergen,
On 12/05/2017 04:19 PM, Juergen Gross wrote:
On 05/12/17 16:23, Julien Grall wrote:
Hi Juergen,
On 04/12/17 15:49, Juergen Gr
On Wed, Dec 06, 2017 at 12:22:00PM +0100, Juergen Gross wrote:
> On 06/12/17 10:53, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 12/05/2017 04:19 PM, Juergen Gross wrote:
> >> On 05/12/17 16:23, Julien Grall wrote:
> >>> Hi Juergen,
> >>>
> >>> On 04/12/17 15:49, Juergen Gross wrote:
> On 2
On 12/06/2017 11:45 AM, Jan Beulich wrote:
On 06.12.17 at 10:47, wrote:
I guess I have been CCed because you would like this patch is fixing the
regression you mentioned on IRC?
Yes, but first of all we need to see whether the issue goes away in
master once the patch is in.
Would revertin
On 11/15/2017 04:46 PM, Julien Grall wrote:
> Hi,
>
> On 11/15/2017 11:29 AM, osstest service owner wrote:
>> flight 116178 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/116178/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including
>>> On 06.12.17 at 10:47, wrote:
> I guess I have been CCed because you would like this patch is fixing the
> regression you mentioned on IRC?
Yes, but first of all we need to see whether the issue goes away in
master once the patch is in.
Jan
___
X
Hi, Stefano.
On Tue, Dec 5, 2017 at 9:24 PM, Stefano Stabellini
wrote:
> On Tue, 5 Dec 2017, Oleksandr Tyshchenko wrote:
>> >> Another question is second_max_freq. As I understand, it is highest
>> >> non-turbo frequency calculated by framework to limit target frequency
>> >> when
>> >> turbo mod
1 - 100 of 114 matches
Mail list logo
