>>> On 30.10.17 at 02:51, wrote:
> On 2017年10月18日 22:05, Roger Pau Monné wrote:
>>> +int viommu_register_type(uint64_t type, struct viommu_ops *ops)
>>> > +{
>>> > +struct viommu_type *viommu_type = NULL;
>>> > +
>>> > +if ( !viommu_enabled() )
>>> > +return -ENODEV;
>>> > +
>>> >
>>> On 30.10.17 at 03:21, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, October 27, 2017 5:19 PM
>> >>> On 27.10.17 at 10:28, wrote:
>> > RAS:
>> > [BUG] xen-mceinj tool testing cause dom0 crash
>> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html
>>
flight 115600 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 16 guest-start.2 fail in 115575 REGR. vs. 114507
Tests which are f
Hi Jan
We have update of this issue and I sent mail two three days ago, maybe you
haven't read it yet, but I think you'll read it soon.
Thanks,
-Xudong
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 6, 2017 4:24 PM
> To: Hao, Xudong
> Cc:
flight 115605 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs.
115476
Tests which are fail
>>> On 03.11.17 at 09:29, wrote:
> We figured out the problem, some corner scripts triggered the error
> injection at the same page (pfn 0x180020) twice, i.e. "./xen-mceinj -t 0" run
> over one time, which resulted in Dom0 crash.
But isn't this a valid scenario, which shouldn't result in a kern
Hello All,
I am a little confused about mapping mechanism in Xen for page from DomU to
Dom0.
When Dom0 maps DomU page to its applied host_addr, Page table entries are
created by Xen hypervisor for mapping applied host_addr vritual address of
Dom0 to DomU physical page. The result is host_add
On 06/11/17 10:57, Waseem, Amna wrote:
> Hello All,
>
> I am a little confused about mapping mechanism in Xen for page from DomU to
> Dom0.
>
> When Dom0 maps DomU page to its applied host_addr, Page table entries are
> created by Xen hypervisor for mapping applied host_addr vritual address o
On Mon, Nov 06, 2017 at 04:38:51AM +, HUANG SHENGQIANG wrote:
> Dear XEN expert,
>
> I find a blocker issue in my project. Would you please offer us some feedback?
>
> The description from my development team:
> we need restore as much as xen snapshot at same times, but we found ‘xl
> restor
flight 72429 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72429/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 72376
test-armhf-armhf-armhf-sid-n
Thanks a lot
I understood it now
From: Juergen Gross
Sent: Monday, November 6, 2017 11:24 AM
To: Waseem, Amna; Julien Grall
Cc: xen-devel; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Confused about mapped pages "struct page" updates
On 06/11/17 10:5
>>> On 26.10.17 at 11:19, wrote:
> --- a/xen/common/gcov/gcov.c
> +++ b/xen/common/gcov/gcov.c
> @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
> break;
>
> default:
> -ret = -EINVAL;
> +ret = -ENOSYS;
> break;
> }
Very certainl
> -Original Message-
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 02 November 2017 18:06
> To: Xen Development List
> Cc: Joao Martins ; Konrad Rzeszutek Wilk
> ; Paul Durrant ; Wei Liu
>
> Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
> parameters
As soft-affinity and caps will be available in Xen 4.10.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Julien Grall
Cc: Lars Kurth
---
Julien, doc change, so no risk.
Sorry I missed doing this at the same time of the changes themselves.
---
docs/features/sched_credit2.pandoc | 13
>>> On 27.10.17 at 16:18, wrote:
> Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> need expose to guest.wq
First of all, please don't forget to Cc relevant maintainers.
> The bit definition:
> CPUID.(EAX=7,ECX=0)
>>> On 31.10.17 at 11:49, wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -44,7 +44,13 @@ static void check_lock(struct lock_debug *debug)
> if ( unlikely(debug->irq_safe != irq_safe) )
> {
> int seen = cmpxchg(&debug->irq_safe, -1, irq_safe);
> -
Jan Beulich writes ("Re: [PATCH for-next 1/9] gcov: return ENOSYS for
unimplemented gcov domctl"):
> On 26.10.17 at 11:19, wrote:
> > --- a/xen/common/gcov/gcov.c
> > +++ b/xen/common/gcov/gcov.c
> > @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
> > break;
> >
>
On 03/11/17 13:17, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>> On Fri, Sep 29, 2017 at 03:33:58PM +, Juergen Gross wrote:
On 29/09/17 17:24, Roger Pau Monné wrote:
> On Fri, Sep 29, 2017 at 02:
>>> On 01.11.17 at 15:03, wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
> of the function use mfn_t.
>
> So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
> MFN
flight 115597 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115597/
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. 114814
Tests which are faili
On 11/06/2017 10:35 AM, Dario Faggioli wrote:
> As soft-affinity and caps will be available in Xen 4.10.
>
> Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi Jan,
On 06/11/17 11:37, Jan Beulich wrote:
On 01.11.17 at 15:03, wrote:
Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of the function use mfn_t.
So I think it is time to make __page_to_mfn an
>>> On 16.10.17 at 14:42, wrote:
On 16.10.17 at 14:37, wrote:
> > On 16/10/17 13:32, Jan Beulich wrote:
> >> Since the emulator acts on the live hardware registers, we need to
> >> prevent the compiler from using them e.g. for inlined memcpy() /
> >> memset() (as gcc7 does). We can't, howeve
>>> On 06.11.17 at 12:16, wrote:
> Jan Beulich writes ("Re: [PATCH for-next 1/9] gcov: return ENOSYS for
> unimplemented gcov domctl"):
>> On 26.10.17 at 11:19, wrote:
>> > --- a/xen/common/gcov/gcov.c
>> > +++ b/xen/common/gcov/gcov.c
>> > @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysct
>>> On 06.11.17 at 12:47, wrote:
> Hi Jan,
>
> On 06/11/17 11:37, Jan Beulich wrote:
> On 01.11.17 at 15:03, wrote:
>>> Most of the users of page_to_mfn and mfn_to_page are either overriding
>>> the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
>>> of the function use
On 06/11/17 12:11, Jan Beulich wrote:
On 06.11.17 at 12:47, wrote:
Hi Jan,
On 06/11/17 11:37, Jan Beulich wrote:
On 01.11.17 at 15:03, wrote:
Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of
Sorry for the slow response.
Ian Jackson writes:
> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry. This will be useful in certain
> Xen configurations.
>
> Signed-off-by: Ian Jackson
> ---
> v3: Error messages fixed. Thanks to Pe
On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> > Sent: 02 November 2017 18:06
> > To: Xen Development List
> > Cc: Joao Martins ; Konrad Rzeszutek Wilk
> > ; Paul Durrant ; Wei Liu
> >
> > Su
>>> On 04.11.17 at 05:48, wrote:
> I added some additional storage to my server with some native 4k sector
> size disks. The LVM volumes on that array seem to work fine when mounted
> by the host, and when passed through to any of the Linux guests, but
> Windows guests aren't able to use them whe
>>> On 03.11.17 at 18:35, wrote:
> * Add more feature names to ./xen-cpuid
> * Vertically align the magic comments in cpufeatureset.h
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
>>> On 06.11.17 at 13:16, wrote:
>
> On 06/11/17 12:11, Jan Beulich wrote:
> On 06.11.17 at 12:47, wrote:
>>> Hi Jan,
>>>
>>> On 06/11/17 11:37, Jan Beulich wrote:
>>> On 01.11.17 at 15:03, wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the ma
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-i386-pvgrub
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.
On Mon, Nov 06, 2017 at 05:35:10AM -0700, Jan Beulich wrote:
> >>> On 03.11.17 at 18:35, wrote:
> > * Add more feature names to ./xen-cpuid
> > * Vertically align the magic comments in cpufeatureset.h
> >
> > Signed-off-by: Andrew Cooper
>
> Acked-by: Jan Beulich
>
>
Acked-by: Wei Liu
flight 115599 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel broken in 115585
test-amd64-i386-libvirt-qcow2 1
On 11/06/2017 02:16 AM, Juergen Gross wrote:
> On 03/11/17 20:00, Boris Ostrovsky wrote:
>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>> On 03/11/17 19:35, Boris Ostrovsky wrote:
On 11/03/2017 02:23 PM, Juergen Gross wrote:
> On 03/11/17 19:19, Boris Ostrovsky wrote:
>> On 11/03/20
On Mon, Nov 06, 2017 at 01:47:56PM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-i386-pvgrub
> testid guest-start
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
On 11/06/2017 11:59 AM, Jan Beulich wrote:
On 16.10.17 at 14:42, wrote:
> On 16.10.17 at 14:37, wrote:
>>> On 16/10/17 13:32, Jan Beulich wrote:
Since the emulator acts on the live hardware registers, we need to
prevent the compiler from using them e.g. for inlined memcpy() /
>
On 06/11/17 15:51, Boris Ostrovsky wrote:
> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
On 03/11/17 19:35, Boris Ostrovsky wrote:
> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>> On 03/11/17
Hi. Thanks for the (re)-review.
Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new
-runasid option"):
> Ian Jackson writes:
> > +case QEMU_OPTION_runasid:
> > +errno = 0;
> > +lv = strtoul(optarg, &ep, 0); /* can't qemu_strtoul, want *ep=='.'
> >
On 19/10/2017 15:39, Joao Martins wrote:
> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> on kvmclock since:
>
> commit dac16fba6fc5
> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>
> The only user of this interface so far is kvm. This commit adds a
osstest service owner writes ("[linux-4.9 test] 115538: regressions - FAIL"):
> flight 115538 linux-4.9 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115538/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-am
On 11/06/2017 10:05 AM, Juergen Gross wrote:
> On 06/11/17 15:51, Boris Ostrovsky wrote:
>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>> On 03/11/17 20:00, Boris Ostrovsky wrote:
On 11/03/2017 02:40 PM, Juergen Gross wrote:
> On 03/11/17 19:35, Boris Ostrovsky wrote:
>> On 11/03/20
This makes the output of mg-force-push quite unpleasant, amongst other
things.
Signed-off-by: Ian Jackson
---
ap-push | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ap-push b/ap-push
index a27ccc2..6c95b1f 100755
--- a/ap-push
+++ b/ap-push
@@ -17,7 +17,7 @@
# along with th
This does some safety checks and reduces the risk of c&p mistakes.
It has to be run as osst...@osstest.test-lab (or equivalent).
Signed-off-by: Ian Jackson
---
mg-force-push | 121 ++
1 file changed, 121 insertions(+)
create mode 100755 mg
flight 115609 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 16 guest-start.2 fail in 115575 REGR. vs. 114507
Tests which are f
flight 115616 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115616/
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
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.
- It starts with the device being bound to us, for which we do a function
reset (done via SysFS so the PCI lock is held).
- If the device is unbound from us, we also do a function re
On 11/03/2017 06:35 PM, Juergen Gross wrote:
> On 03/11/17 19:29, Roger Pau Monné wrote:
>> On Fri, Nov 03, 2017 at 05:57:52PM +, George Dunlap wrote:
>>> On 11/03/2017 02:52 PM, George Dunlap wrote:
On 11/03/2017 02:14 PM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 09:55:11AM +0
Ian Jackson writes:
> Hi. Thanks for the (re)-review.
>
> Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new
> -runasid option"):
>> Ian Jackson writes:
>> > +case QEMU_OPTION_runasid:
>> > +errno = 0;
>> > +lv = strtoul(optarg, &ep, 0); /* can't
flight 115610 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 115599
Tests which did not
On 11/02/2017 05:19 AM, Juergen Gross wrote:
> In order to support Linux to run as a pv guest on machines with huge
> memory (>16TB) or as a hvm guest with more than 16TB of memory the
> kernel has to support grant table interface v2, as v1 is limited to
> 32 bit frame numbers.
>
> This series re-a
flight 115606 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115606/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 11 guest-start fail REGR. vs. 115526
test-amd64-amd64-i
flight 115613 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115613/
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. 114814
Tests which are faili
On Sat, 4 Nov 2017, Dan Carpenter wrote:
> Hello Stefano Stabellini,
>
> The patch 235a71c53903: "xen/pvcalls: implement release command" from
> Oct 30, 2017, leads to the following static checker warning:
>
> drivers/xen/pvcalls-front.c:1051 pvcalls_front_release()
> error: double lo
When QEMU emulates a GICv3, it needs to advertise the presence of the
system register interface, which is done via id_aa64pfr0.
To do that, and at the same time to avoid advertising the presence of
the system register interface when it is actually not available, set a
boolean property in machvirt_
mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
take in_mutex on the first try, but you can't take out_mutex. Next times
you call mutex_trylock() in_mutex is going to fail. It's an endless
loop.
Solve the problem by moving the two mutex_trylock calls to two separate
loops.
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v2] aarch64: advertise the GIC system register
interface
Type: series
Message-id: alpine.DEB.2.10.1711061412330.30448@sstabellini-ThinkPad-X260
=== TEST SCRIPT BEGIN ===
On 11/06/2017 05:17 PM, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> take in_mutex on the first try, but you can't take out_mutex. Next times
> you call mutex_trylock() in_mutex is going to fail. It's an endless
> loop.
>
> Solve the problem
On Mon, 6 Nov 2017, Boris Ostrovsky wrote:
> On 11/06/2017 05:17 PM, Stefano Stabellini wrote:
> > mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> > take in_mutex on the first try, but you can't take out_mutex. Next times
> > you call mutex_trylock() in_mutex is going to f
flight 115615 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs.
114682
test-amd64-amd64
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 6, 2017 5:17 PM
> To: Hao, Xudong
> Cc: Julien Grall ; George Dunlap
> ; Lars Kurth ; Zhang,
> Haozhong ; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [BUG] xen-mceinj tool testing cause dom0
flight 115620 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 12 guest-start fail REGR. vs. 114507
test-amd64-amd64-
On 10/30/2017 06:17 AM, Wei Liu wrote:
Hi Jim
I discover a problem when using xen_xl converter. When the file in
question doesn't end with a new line, I get the following error:
error: configuration file syntax error: memory conf:53: expecting a value
I'm not able to reproduce this issue.
On 06/11/17 23:17, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> take in_mutex on the first try, but you can't take out_mutex. Next times
> you call mutex_trylock() in_mutex is going to fail. It's an endless
> loop.
>
> Solve the problem by m
Hi,
I am trying to bring up OSS test framework on a couple of moonshot
systems which are accessible to me remotely.
While going through [1], I have some queries/doubts on the configuration.
1. The following configuration:
DnsDomain uk.xensource.com
NetNameservers 10.80.248.2 10.80.16.28 10.80.1
On Mon, Nov 06, 2017 at 03:39:45AM -0700, Jan Beulich wrote:
> >>> On 27.10.17 at 16:18, wrote:
> > Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> > VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> > need expose to guest.wq
>
> First of all, please don't forget
On 06/11/17 17:42, Boris Ostrovsky wrote:
> On 11/06/2017 10:05 AM, Juergen Gross wrote:
>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
On 03/11/17 20:00, Boris Ostrovsky wrote:
> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>> On 03/11/17
67 matches
Mail list logo
