On 04/09/2018 05:12 PM, George Dunlap wrote:
> The obvious place to look is the logdirtyvram functionality, which is
> used to make it easier for QEMU to figure out which bits of the display
> buffer have been modified. One of the big reasons the altp2m
> functionality is still considered "experim
On Tue, Apr 10, Dario Faggioli wrote:
> I remember specifically wanting for it to support not only "nodes:", but also
> "node:", because I thought that, e.g., "nodes:3" would have sound weird to
> users.
It turned out that I had a typo all the time in my template, it used
'cpu=' rather than 'cpus
flight 122158 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122158/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 13d909f89a3cee1c1f6b851a4cda7bd1a44e90ae
baseline version:
ovmf 64797018df0cf5c1f1152
On 10/04/18 19:22, Ian Jackson wrote:
> The SUPPORT.md document (introduced in 4.10) does not appear here
> http://xenbits.xen.org/docs/
> In this series I fix this.
>
> This is a prerequisite for my work to generate a matrix representing
> the cross-version feature support status, because that
flight 122154 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5 host-build-pre
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 10, 2018 4:44 PM
>
> >>> On 09.04.18 at 19:56, wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -1788,7 +1788,10 @@ void vmcs_dump_vcpu(struct vcpu *v)
> > vmentry_ctl = vmr32(VM_EN
flight 122145 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 121320
Tests which did not
pcistub_reg_add() is never called in atomic context.
pcistub_reg_add() is only called by pcistub_quirk_add, which is
only set in DRIVER_ATTR().
Despite never getting called from atomic context,
pcistub_reg_add() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is
On 2018/4/10 23:01, Boris Ostrovsky wrote:
On 04/10/2018 10:31 AM, Jia-Ju Bai wrote:
On 2018/4/10 22:27, Boris Ostrovsky wrote:
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
pcistub_probe() is never called in atomic context.
This function is only set as ".probe" in struct pci_driver.
Despite
flight 122144 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122144/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120095
test-amd64-amd64-xl-qemuu-win7-amd6
[Adding Andrew, not because I expect anything, but just because we've
chatted about this issue on IRC :-) ]
On Tue, 2018-04-10 at 22:37 +0200, Olaf Hering wrote:
> On Tue, Apr 10, Dario Faggioli wrote:
>
> BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc)));
>
> (XEN) Xen BUG at sched_credit.c:876
> (X
This run is configured for baseline tests only.
flight 74572 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74572/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 64797018df0cf5c1f11523bb575355aba918b940
baseline v
flight 122143 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
Il Mar 10 Apr 2018, 22:16 Olaf Hering ha scritto:
> On Tue, Apr 10, Olaf Hering wrote:
>
> > On Tue, Apr 10, Dario Faggioli wrote:
> >
> > > In the meanwhile --let me repeat myself-- just go ahead with "node:2",
> > > "node:3", etc. :-D
> >
> > I did, and that fails.
>
> I think the man page is n
On Tue, Apr 10, Dario Faggioli wrote:
> So, Olaf, if you're fancy giving this a tray anyway, well, go ahead.
BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc)));
(XEN) Xen BUG at sched_credit.c:876
(XEN) [ Xen-4.11.20180410T125709.50f8ba84a5-3.bug1087289_411 x86_64
debug=y Not tainted ]
(XE
On Tue, Apr 10, Olaf Hering wrote:
> On Tue, Apr 10, Dario Faggioli wrote:
>
> > In the meanwhile --let me repeat myself-- just go ahead with "node:2",
> > "node:3", etc. :-D
>
> I did, and that fails.
I think the man page is not that clear, to me. If there is a difference
between 'node' vs. 'n
On Tue, Apr 10, Dario Faggioli wrote:
> In the meanwhile --let me repeat myself-- just go ahead with "node:2",
> "node:3", etc. :-D
I did, and that fails.
Olaf
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenpro
On Tue, 2018-04-10 at 21:03 +0200, Olaf Hering wrote:
> On Tue, Apr 10, Dario Faggioli wrote:
>
> > As said, its cpus= and cpus_soft=, and you probably just need
> > cpus="node:1"
> > cpus_soft="node:1"
> > Or, even just:
> > cpus="node:1"
> > as, if soft-affinity is set to be equal to hard, it is
On 2017-09-21 18:12:54 +0100, Ian Jackson wrote:
> Venu Busireddy writes ("Re: [PATCH v3 1/2] libxl: Implement the handler to
> handle unrecoverable AER errors"):
> > On 2017-08-08 15:33:01 +0100, Wei Liu wrote:
> > > I think a bigger question is whether you agree with Ian's comments
> > > regardi
On 2018-04-03 17:51:50 +0100, Ian Jackson wrote:
> Venu Busireddy writes ("Re: [PATCH v3 1/2] libxl: Implement the handler to
> handle unrecoverable AER errors [and 1 more messages]"):
> > On 2018-04-03 16:06:17 +0100, Ian Jackson wrote:
> > > Ian Jackson writes ("Re: [PATCH v3 1/2] libxl: Impleme
On Tue, Apr 10, Dario Faggioli wrote:
> On Tue, 2018-04-10 at 17:59 +0200, Olaf Hering wrote:
> > memory=
> > vcpus=36
> > cpu="nodes:1,^node:0"
> > cpu_soft="nodes:1,^node:0"
> As said, its cpus= and cpus_soft=, and you probably just need
> cpus="node:1"
> cpus_soft="node:1"
> Or, even just:
this function returns the "epoch" time
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 39 +++
include/xtf/time.h | 5 +
2 files changed, 44 insertions(+)
diff --git a/common/time.c b/common/time.c
index 79abc7
this function uses nspin_sleep to spin sleep for t seconds
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/time.c b/common/time.c
index 232e134..87db124 100644
--- a/common/time.c
+++ b/common/t
this function uses mspin_sleep to spin sleep for t milliseconds
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 6 ++
include/xtf/time.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/common/time.c b/common/time.c
index 87db124..7515eb0 1006
this function spin sleeps for t nanoseconds
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 12
1 file changed, 12 insertions(+)
diff --git a/common/time.c b/common/time.c
index 8489f3b..232e134 100644
--- a/common/time.c
+++ b/common/time.c
@
this function acts as the POSIX gettimeofday function
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 30 ++
include/xtf/time.h | 8
2 files changed, 38 insertions(+)
diff --git a/common/time.c b/common/time.c
ind
those are helpful macro to use the time manager correctly
Signed-off-by: Paul Semel
---
Notes:
v4:
- new patch version
common/time.c | 10 ++
include/xtf/time.h | 12
2 files changed, 22 insertions(+)
diff --git a/common/time.c b/common/time.c
index 7515eb0..
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
moment the VM has booted
Signed-off-by: Paul Semel
This run is configured for baseline tests only.
flight 74570 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74570/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64
We are going to want to format SUPPORT.md which does not match the
filename patterns in docs/. So provide a way to make an ad-hoc rule
using pandoc with the standard options.
No functional change in this patch.
Signed-off-by: Ian Jackson
---
docs/Makefile | 11 ++-
1 file changed, 6 in
Signed-off-by: Ian Jackson
---
docs/gen-html-index | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/gen-html-index b/docs/gen-html-index
index e9792bf..5b43b42 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -10,6 +10,7 @@ use warnings;
use Getopt::Long;
use
There are none yet.
Signed-off-by: Ian Jackson
---
docs/gen-html-index | 4
1 file changed, 4 insertions(+)
diff --git a/docs/gen-html-index b/docs/gen-html-index
index 5b43b42..8258e2b 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -137,6 +137,10 @@ sub dirs($)
return
Signed-off-by: Ian Jackson
---
SUPPORT.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index e447069..264b23f 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -1,4 +1,4 @@
-# Support statement for this release
+% Support statement for this release
This
The SUPPORT.md document (introduced in 4.10) does not appear here
http://xenbits.xen.org/docs/
In this series I fix this.
This is a prerequisite for my work to generate a matrix representing
the cross-version feature support status, because that cross-version
matrix wants to contain hyperlinks i
Signed-off-by: Ian Jackson
---
SUPPORT.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 1c5220b..e447069 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -360,7 +360,7 @@ Guest-side driver capable of speaking the Xen PV block
protocol
Status, F
Continuations of bullet list items must be indented by exactly 4
spaces (according to pandoc_markdown(5) on Debian jessie).
This is most easily achieved by making the bullet list items have two
spaces before the `*'.
Signed-off-by: Ian Jackson
---
SUPPORT.md | 36 ++-
Signed-off-by: Ian Jackson
---
docs/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/Makefile b/docs/Makefile
index d82463f..b300bb6 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -28,7 +28,8 @@ DOC_MAN7 := $(patsubst man/%.pod.7,man7/%.7,$(MAN7SRC-y)) \
On Tue, 2018-04-10 at 16:25 +0100, George Dunlap wrote:
> On 04/10/2018 12:29 PM, Dario Faggioli wrote:
> >
> One thing we might consider doing is implementing the migrate()
> callback
> for the Credit scheduler, and just have it make a bunch of sanity
> checks
> (v->processor lock held, new_cpu l
On Tue, 2018-04-10 at 17:59 +0200, Olaf Hering wrote:
> On Tue, Apr 10, Olaf Hering wrote:
>
> > (XEN) Xen BUG at sched_credit.c:1694
>
> And another one with debug=y and this config:
>
Wow...
> memory=
> vcpus=36
> cpu="nodes:1,^node:0"
> cpu_soft="nodes:1,^node:0"
>
As said, its cpus= and
flight 122162 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122162/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Apr 10, Olaf Hering wrote:
> (XEN) Xen BUG at sched_credit.c:1694
And another one with debug=y and this config:
memory=
vcpus=36
cpu="nodes:1,^node:0"
cpu_soft="nodes:1,^node:0"
(nodes=1 cycles between 1-3 for each following domU).
(XEN) Assertion 'CSCHED_PCPU(cpu)->nr_runnable >= 1'
On Tue, 2018-04-10 at 16:25 +0100, George Dunlap wrote:
> On 04/10/2018 12:29 PM, Dario Faggioli wrote:
> >
> whenever that is. (Possibly at the end of the current call to
> vcpu_migrate(), possibly at the end of a vcpu_migrate() triggered in
> context_saved() due to VPF_migrating.)
>
> vcpu_mig
On 04/10/2018 04:18 PM, Olaf Hering wrote:
> On Tue, Apr 10, Olaf Hering wrote:
>
>> (XEN) Xen BUG at sched_credit.c:1694
>
> Another variant:
>
> This time the domUs had just vcpus=36 and
> cpus=nodes:N,node:^0/cpus_soft=nodes:N,node:^0
>
> (XEN) Xen BUG at sched_credit.c:280
> (XEN) [ Xe
On 04/10/2018 12:29 PM, Dario Faggioli wrote:
> On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
>> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
>>> On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
Assuming the bug is this one:
BUG_ON( cpu != snext->vcpu->processor );
On Tue, Apr 10, Olaf Hering wrote:
> (XEN) Xen BUG at sched_credit.c:1694
Another variant:
This time the domUs had just vcpus=36 and
cpus=nodes:N,node:^0/cpus_soft=nodes:N,node:^0
(XEN) Xen BUG at sched_credit.c:280
(XEN) [ Xen-4.11.20180407T144959.e62e140daa-2.bug1087289_411 x86_64
deb
On 04/10/2018 10:31 AM, Jia-Ju Bai wrote:
>
>
>
> On 2018/4/10 22:27, Boris Ostrovsky wrote:
>> On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
>>> pcistub_probe() is never called in atomic context.
>>> This function is only set as ".probe" in struct pci_driver.
>>>
>>> Despite never getting called from
On 2018/4/10 22:27, Boris Ostrovsky wrote:
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
pcistub_probe() is never called in atomic context.
This function is only set as ".probe" in struct pci_driver.
Despite never getting called from atomic context,
pcistub_probe() calls kmalloc() with GFP_ATOMIC
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
> pcistub_probe() is never called in atomic context.
> This function is only set as ".probe" in struct pci_driver.
>
> Despite never getting called from atomic context,
> pcistub_probe() calls kmalloc() with GFP_ATOMIC,
> which does not sleep for allocation
On 04/09/2018 02:51 PM, Boris Ostrovsky wrote:
> Pre-4.17 kernels ignored start_info's rsdp_paddr pointer and instead
> relied on finding RSDP in standard location in BIOS RO memory. This
> has worked since that's where Xen used to place it.
>
> However, with recent Xen change (commit 4a5733771e6f
flight 122159 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122159/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:
- guest active and in kernel mode
- guest active and in user mode
- hypervis
Instead of switching XPTI globally on or off add a per-domain flag for
that purpose. This allows to modify the xpti boot parameter to support
running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot
parameter will achieve that.
Move the xpti boot parameter handling to xen/arch/x86/pv
On 10/04/2018, 09:12, "Juergen Gross" wrote:
On 09/04/18 17:02, Lars Kurth wrote:
> Note: this time with html disabled
>
> To become a CNA, we need to more clearly specifiy the scope of
> security support. This change updates the document and points
> to SUPPORT.md and
On 09/04/18 15:23, Jan Beulich wrote:
> We don't break up port requests in case they cross emulation entity
> boundaries, and a write to an I/O port is necessarily the last
> operation of an instruction instance, so there's no need to re-invoke
> the full emulation path upon receiving the result fr
flight 122132 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 121318
On 10/04/18 13:24, Julien Grall wrote:
> c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
> libxl__domain_build_state" removed state->config completely but missed
> some conversion libxl_arm.c.
>
> Furthermore, not all the fields of xc_domain_configuration_t have a
> corresponding f
On Tue, Apr 10, 2018 at 12:24:53PM +0100, Julien Grall wrote:
> c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
> libxl__domain_build_state" removed state->config completely but missed
> some conversion libxl_arm.c.
>
> Furthermore, not all the fields of xc_domain_configuration_t h
On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> > On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> > > Assuming the bug is this one:
> > >
> > > BUG_ON( cpu != snext->vcpu->processor );
> > >
> >
> > Yes, it is that one.
> >
> >
On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> > On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> > > Assuming the bug is this one:
> > >
> > > BUG_ON( cpu != snext->vcpu->processor );
> > >
> >
> > Yes, it is that one.
> >
> >
On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> > On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> > > Assuming the bug is this one:
> > >
> > > BUG_ON( cpu != snext->vcpu->processor );
> > >
> >
> > Yes, it is that one.
> >
> >
On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> > On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> > > Assuming the bug is this one:
> > >
> > > BUG_ON( cpu != snext->vcpu->processor );
> > >
> >
> > Yes, it is that one.
> >
> >
On Tue, 2018-04-10 at 11:59 +0100, George Dunlap wrote:
> On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> > On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> > > Assuming the bug is this one:
> > >
> > > BUG_ON( cpu != snext->vcpu->processor );
> > >
> >
> > Yes, it is that one.
> >
> >
flight 74569 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74569/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-a
c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
libxl__domain_build_state" removed state->config completely but missed
some conversion libxl_arm.c.
Furthermore, not all the fields of xc_domain_configuration_t have a
corresponding field in libxl_domain_build_info. This is the case o
On 04/10/2018 01:47 PM, Julien Grall wrote:
Hi,
On 04/10/2018 09:53 AM, Oleksandr Andrushchenko wrote:
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
diff --git a/drivers/dma-buf/hyper_dmabuf/hyper_dmabuf_id.h
[...]
+#ifndef __HYPER_DMABUF_ID_H__
+#define __HYPER_DMABUF_ID_H__
+
+#define HYPER
On 04/10/2018 11:33 AM, Dario Faggioli wrote:
> On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
>> Assuming the bug is this one:
>>
>> BUG_ON( cpu != snext->vcpu->processor );
>>
> Yes, it is that one.
>
> Another stack trace, this time from a debug=y built hypervisor, of what
> we are thi
Hi,
On 04/10/2018 09:53 AM, Oleksandr Andrushchenko wrote:
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
diff --git a/drivers/dma-buf/hyper_dmabuf/hyper_dmabuf_id.h
[...]
+#ifndef __HYPER_DMABUF_ID_H__
+#define __HYPER_DMABUF_ID_H__
+
+#define HYPER_DMABUF_ID_CREATE(domid, cnt) \
+ domi
On 04/10/2018 12:36 PM, Roger Pau Monné wrote:
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
mom
On Tue, Apr 10, 2018 at 12:32:23PM +0200, Paul Semel wrote:
> On 04/10/2018 12:05 PM, Roger Pau Monné wrote:
> > > > > > > this file is introduce to be able to implement an inter domain
> > > > > > > communication protocol over xenstore. For synchronization
> > > > > > > purpose, we do
> > > > > >
On Tue, 2018-04-10 at 09:34 +, George Dunlap wrote:
> Assuming the bug is this one:
>
> BUG_ON( cpu != snext->vcpu->processor );
>
Yes, it is that one.
Another stack trace, this time from a debug=y built hypervisor, of what
we are thinking it is the same bug (although reproduced in a slightl
On 04/10/2018 12:05 PM, Roger Pau Monné wrote:
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
mom
flight 122157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
On Tue, Apr 10, 2018 at 11:47:11AM +0200, Paul Semel wrote:
> On 04/10/2018 10:08 AM, Roger Pau Monné wrote:
> > > > > this file is introduce to be able to implement an inter domain
> > > > > communication protocol over xenstore. For synchronization purpose, we
> > > > > do
> > > > > really want t
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Use threaded interrupt intead of regular one because most part of ISR
is time-critical and possibly sleeps
Signed-off-by: Dongwon Kim
---
.../hyper_dmabuf/backends/xen/hyper_dmabuf_xen_comm.c | 19 +++
1 file changed, 11 insertions(+
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Define a private data (e.g. meta data for the buffer) attached to
each hyper_DMABUF structure. This data is provided by userapace via
export_remote IOCTL and its size can be up to 192 bytes.
Signed-off-by: Dongwon Kim
Signed-off-by: Mateusz Polrola
--
Sorry for top-posting
Can we have all this go into some header file which
will not only describe the structures/commands/responses/etc,
but will also allow drivers to use those directly without
defining the same one more time in the code? For example,
this is how it is done in Xen [1]. This w
On 10/04/18 11:36, Jan Beulich wrote:
On 10.04.18 at 11:32, wrote:
>> On 10/04/18 11:14, Jan Beulich wrote:
>> On 10.04.18 at 09:58, wrote:
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1955,14 +1955,29 @@ clustered mode. The defa
On 04/10/2018 10:08 AM, Roger Pau Monné wrote:
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
mom
>>> On 10.04.18 at 11:32, wrote:
> On 10/04/18 11:14, Jan Beulich wrote:
> On 10.04.18 at 09:58, wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1955,14 +1955,29 @@ clustered mode. The default, given no hint from
>>> the **FADT**, i
>>> On 10.04.18 at 10:53, wrote:
> On Mon, Apr 09, 2018 at 09:34:57AM -0600, Jan Beulich wrote:
>> >>> On 30.03.18 at 14:35, wrote:
>> > Execute periodic_time callbacks even if the interrupt is not actually
>> > injected because the IRQ is masked.
>> >
>> > Current callbacks from emulated timer
On 10/04/18 11:29, Jan Beulich wrote:
On 10.04.18 at 09:58, wrote:
>> @@ -102,14 +104,34 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long
>> cr4)
>> old_cr4 = read_cr4();
>> if ( old_cr4 & X86_CR4_PGE )
>> {
>> +/*
>> + * X86_CR4_PGE set means PCID is in
> On Apr 10, 2018, at 9:57 AM, Olaf Hering wrote:
>
> While hunting some other bug we run into the single BUG in
> sched_credit.c:csched_load_balance(). This happens with all versions
> since 4.7, staging is also affected. Testsystem is a Haswell model 63
> system with 4 NUMA nodes and 144 thre
On 10/04/18 11:14, Jan Beulich wrote:
On 10.04.18 at 09:58, wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1955,14 +1955,29 @@ clustered mode. The default, given no hint from the
>> **FADT**, is cluster
>> mode.
>>
>> ### xpti
>>
>>> On 10.04.18 at 09:58, wrote:
> @@ -102,14 +104,34 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long
> cr4)
> old_cr4 = read_cr4();
> if ( old_cr4 & X86_CR4_PGE )
> {
> +/*
> + * X86_CR4_PGE set means PCID is inactive.
> + * We have to purge the TLB
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
From: "Matuesz Polrola"
The default backend for XEN hypervisor. This backend contains actual
implementation of individual methods defined in "struct hyper_dmabuf_bknd_ops"
defined as:
struct hyper_dmabuf_bknd_ops {
/* backend initialization r
On 10/04/18 11:00, Jan Beulich wrote:
On 10.04.18 at 09:58, wrote:
>> For mitigation of Meltdown the current L4 page table is copied to the
>> cpu local root page table each time a 64 bit pv guest is entered.
>>
>> Copying can be avoided in cases where the guest L4 page table hasn't
>> been m
flight 122138 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122138/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 6f45086733cc1ce92ec093533097900a0de1c7b4
baseline version:
xtf 1498952b2417271ac4767c
>>> On 10.04.18 at 09:58, wrote:
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -288,6 +288,16 @@ static inline void write_cr3(unsigned long val)
> asm volatile ( "mov %0, %%cr3" : : "r" (val) : "memory" );
> }
>
> +static inline unsigned long cr3_pa(u
>>> On 10.04.18 at 09:58, wrote:
> pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
> it from a macro to an ordinary function.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@list
>>> On 10.04.18 at 09:58, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will remove
>>> On 10.04.18 at 09:58, wrote:
> If possible use the INVPCID instruction for flushing the TLB instead of
> toggling cr4.pge for that purpose.
>
> While at it remove the dependency on cr4.pge being required for mtrr
> loading, as this will be required later anyway.
>
> Add a command line option
>>> On 10.04.18 at 09:58, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1955,14 +1955,29 @@ clustered mode. The default, given no hint from the
> **FADT**, is cluster
> mode.
>
> ### xpti
> -> `= `
> +> `= List of [ default | | dom0= |
flight 122135 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122135/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 64797018df0cf5c1f11523bb575355aba918b940
baseline version:
ovmf 95cc4962167572089a99b
>>> On 10.04.18 at 09:58, wrote:
> Instead of having multiple places with more or less identical asm
> statements just have one function doing a write to cr3.
>
> As this function should be named write_cr3() rename the current
> write_cr3() function to switch_cr3().
>
> Suggested-by: Andrew Copp
>>> On 10.04.18 at 09:58, wrote:
> For mitigation of Meltdown the current L4 page table is copied to the
> cpu local root page table each time a 64 bit pv guest is entered.
>
> Copying can be avoided in cases where the guest L4 page table hasn't
> been modified while running the hypervisor, e.g.
(Add back xen-devel)
Hello Peter
Please don't top-post.
On Tue, Apr 10, 2018 at 08:52:10AM +, Peter McLaren wrote:
> Hi Wei
> I would like the restore command to return the HVM to the exact state it was
> at when the save command was performed.
> Thanks
> Peter
I think what you need is dis
While hunting some other bug we run into the single BUG in
sched_credit.c:csched_load_balance(). This happens with all versions
since 4.7, staging is also affected. Testsystem is a Haswell model 63
system with 4 NUMA nodes and 144 threads.
(XEN) Xen BUG at sched_credit.c:1694
(XEN) [ Xen-4.11.
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Upload of intial version of core framework in hyper_DMABUF driver
enabling DMA_BUF exchange between two different VMs in virtualized
platform based on Hypervisor such as XEN.
Hyper_DMABUF drv's primary role is to import a DMA_BUF from originator
then re
On Mon, Apr 09, 2018 at 09:34:57AM -0600, Jan Beulich wrote:
> >>> On 30.03.18 at 14:35, wrote:
> > Execute periodic_time callbacks even if the interrupt is not actually
> > injected because the IRQ is masked.
> >
> > Current callbacks from emulated timer devices only update emulated
> > register
On Tue, Apr 10, 2018 at 06:07:12AM +, Peter McLaren wrote:
> Hi
> with at least 1 version of Windows 10 (build 16299), the 'xl restore' command
> does not overwrite the previously running HVM. The symptoms are:
> 1) the restore appears to rapidly complete after approx 50% of the time
> 2) fil
1 - 100 of 119 matches
Mail list logo