flight 105657 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105657/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105624
test-armhf-armhf-libvirt 13
It is currently possible for the guest to lock when subscribing
to synchronous vm_events if max_vcpus is larger than the
number of available ring buffer slots. This patch no longer
blocks already paused VCPUs, fixing the issue for this use
case, and wakes up as many blocked VCPUs as there are slots
On 17-02-08 10:56:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2017 at 04:15:53PM +0800, Yi Sun wrote:
> > + Every MSR stores a CBM value. A capacity bitmask (CBM) provides a hint
> > to the
> > + hardware indicating the cache space an application should be limited to
> > as
>
> s/applic
On Wed, Feb 8, 2017 at 9:12 PM, Julien Grall wrote:
>
>
> On 08/02/17 14:18, Julien Grall wrote:
>> Hi,
>>
>> On 07/02/17 15:59, Vijay Kilari wrote:
>>> On Tue, Feb 7, 2017 at 6:57 PM, Julien Grall wrote:
On 07/02/2017 13:25, Vijay Kilari wrote:
>
> On Tue, Feb 7, 2017 at 6
flight 105648 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 3 host-install(3)broken REGR. vs. 105629
test-amd64-i386-xl
flight 105656 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105656/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
This run is configured for baseline tests only.
flight 68540 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68540/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c
baseline v
flight 105654 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
On 02/08/17 10:31 +, Wei Liu wrote:
On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > If any error code is returned when creating a domain, stop the domai
flight 105652 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105652/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c
baseline version:
ovmf 9fe9cf9acb475af9317dc
flight 105653 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105653/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On 02/09/2017 12:54 AM, Wei Liu wrote:
And CC Zhangchen
Thanks, I will apply this patch set before test my patch.
Zhang Chen
On Wed, Feb 08, 2017 at 02:35:27PM +, Wei Liu wrote:
Cc Yi Sun as well.
Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
time to split
flight 105641 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
test-armhf-armhf-xl
On Thu, 9 Feb 2017, Julien Grall wrote:
> On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall wrote:
> > > Hi Tamas,
> > >
> > > Can you please try to configure your e-mail client to use '>' rather than
> > > '
> > > '? It makes quite hard to read the e-ma
flight 105643 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105643/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
On 02/08/17 14:35 +, Wei Liu wrote:
Cc Yi Sun as well.
Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
time to split libxl.c so things are better organised. It's likely this
series will go in before yours, so you will then need to rebase your
series. I don't expect the
This run is configured for baseline tests only.
flight 68539 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68539/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
baseline v
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:43 PM
>
> This results in rather more readable code. No functional change.
>
> All fields currently specified are included, but commented out as no support
> for their use is present.
>
> Signed-off-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 08, 2017 9:37 PM
>
> >>> On 07.02.17 at 18:35, wrote:
> > Current __hvm_copy assumes that the destination memory belongs to the
> > current
> > vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
> >
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:10 PM
>
> The original function doesn't distinguish between Valid and Invalid
> VMfails. Improved function returns error code depending on the outcome:
>
> VMsucceed: 0
> VMfailValid: VM
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:10 PM
>
> Any fail during the original __vmwrite() leads to BUG() which can be
> easily exploited from a guest in the nested vmx mode.
>
> The new function returns error code depending on the outcome:
>
On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
> Hi Julien,
>
> On 3 February 2017 at 19:38, Julien Grall wrote:
> > So if I understand correctly, you don't receive anymore output. Correct?
> > Have you tried to see whether the pl011 driver is receiving interrupt or
> > even Linux calling it.
>
> T
On 08/02/2017 23:28, Tamas K Lengyel wrote:
On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall wrote:
Hi Tamas,
Can you please try to configure your e-mail client to use '>' rather than '
'? It makes quite hard to read the e-mail.
Hm, not sure why it switched but should be fine now.
On 08/02/2
flight 105650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-buildfail REGR. vs. 105642
Tests which
On Wed, 8 Feb 2017, Andrew Cooper wrote:
> On 08/02/2017 19:24, Julien Grall wrote:
> >
> >
> > On 08/02/17 19:21, Andrew Cooper wrote:
> >> On 08/02/17 19:13, Julien Grall wrote:
> >>> Hi Andrew,
> >>>
> >>> On 08/02/17 19:10, Andrew Cooper wrote:
> c/s 11c397c broke the ARM build by introduc
On Wed, 8 Feb 2017, Julien Grall wrote:
> Commit 146786b "efi: create efi_enabled()" introduced a variable
> efi_flags stored in BSS and used to pass information between the stub
> and Xen. However on ARM, BSS is zeroed after the stub has finished to
> run and before Xen is started. This means that
On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall wrote:
> Hi Tamas,
>
> Can you please try to configure your e-mail client to use '>' rather than '
> '? It makes quite hard to read the e-mail.
Hm, not sure why it switched but should be fine now.
> On 08/02/2017 20:15, Tamas K Lengyel wrote:
>>
>>
>>
This run is configured for baseline tests only.
flight 68537 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm
flight 105647 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105647/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-buildfail REGR. vs. 105642
Tests which
This run is configured for baseline tests only.
flight 68538 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68538/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc20411062137e5d820a33db73d41f97dae74368
baseline v
Joao Martins wrote:
> On 02/08/2017 04:06 PM, Jim Fehlig wrote:
>> Joao Martins wrote:
>>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
When the libxl driver is initialized, it creates a virDomainDef
object for dom0 and adds it to the list of domains. Total memory
for dom0 was being set
Hi Tamas,
Can you please try to configure your e-mail client to use '>' rather
than ''? It makes quite hard to read the e-mail.
On 08/02/2017 20:15, Tamas K Lengyel wrote:
On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
mailto:edgar.igles...@gmail.com>> wrote:
On Wed, Feb 08, 201
flight 105640 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR.
vs. 105629
test-ar
On Wed, Feb 8, 2017 at 11:12 AM, George Dunlap
wrote:
> On 08/02/17 17:29, Tim Deegan wrote:
> > At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
> >> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> >> nested p2m tables whenever the host p2m table changed. Unfortun
flight 105645 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-buildfail REGR. vs. 105642
Tests which
On 02/08/2017 02:05 PM, Peter Zijlstra wrote:
> On Wed, Feb 08, 2017 at 01:00:24PM -0500, Waiman Long wrote:
>> It was found when running fio sequential write test with a XFS ramdisk
>> on a 2-socket x86-64 system, the %CPU times as reported by perf were
>> as follows:
>>
>> 71.27% 0.28% fio [k
On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias wrote:
> On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> > On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> > > Hi Tamas,
> > >
> > > On 08/02/17 16:40, Tamas K Lengyel wrote:
> > > >On Wed, Feb 8, 2017 at 1:31
Hi,
On 24/01/17 22:19, David Scott wrote:
>
>> On 24 Jan 2017, at 11:35, Ian Jackson wrote:
>>
>> Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
>> ocamlopt"):
>>> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
>>> package lacks ocamlopt.
>> ...
>
On 02/08/2017 09:29 PM, Julien Grall wrote:
Hi Oleksandr,
On 08/02/17 18:56, Oleksandr Andrushchenko wrote:
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko
On 08/02/2017 19:24, Julien Grall wrote:
>
>
> On 08/02/17 19:21, Andrew Cooper wrote:
>> On 08/02/17 19:13, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 08/02/17 19:10, Andrew Cooper wrote:
c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
which is
different to
On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> > Hi Tamas,
> >
> > On 08/02/17 16:40, Tamas K Lengyel wrote:
> > >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> > >mailto:edgar.igles...@xilinx.com>> wrote:
>
Hi Oleksandr,
On 08/02/17 18:56, Oleksandr Andrushchenko wrote:
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
On 01/30/2017 05:33 PM, Julien Grall
On 08/02/17 18:17, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
On 01/30/2017 05:33 PM, Julien Grall wrote:
This email only tracks big items for xen.git tree. Please r
On 08/02/17 19:21, Andrew Cooper wrote:
On 08/02/17 19:13, Julien Grall wrote:
Hi Andrew,
On 08/02/17 19:10, Andrew Cooper wrote:
c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
which is
different to the definiton in smmu.c
Forgot this one s/definiton/definition/
T
On 08/02/17 19:13, Julien Grall wrote:
> Hi Andrew,
>
> On 08/02/17 19:10, Andrew Cooper wrote:
>> c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
>> which is
>> different to the definiton in smmu.c
>>
>> The SMMU code included a scalar typecheck, which is worth keeping in the
> ## Ring Setup
>
> The shared page has the following layout:
>
> typedef uint32_t XEN_9PFS_RING_IDX;
>
> struct xen_9pfs_intf {
> XEN_9PFS_RING_IDX in_cons, in_prod;
> uint8_t pad[56];
> XEN_9PFS_RING_IDX out_cons, out_prod;
>
> uint32_t ring_order;
> /*
Hi Andrew,
On 08/02/17 19:10, Andrew Cooper wrote:
c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE() which is
different to the definiton in smmu.c
The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions. Howev
flight 105644 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 15 guest-localmigrate/x10 fail REGR.
vs. 105642
b
c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE() which is
different to the definiton in smmu.c
The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions. However, express the
typecheck differently so as to avoid C
On 02/08/2017 02:05 PM, Peter Zijlstra wrote:
> On Wed, Feb 08, 2017 at 01:00:25PM -0500, Waiman Long wrote:
>> As the vcpu_is_preempted() call is pretty costly compared with other
>> checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
>> are done at a reduce frequency of once every
Hi Stefano,
On 02/02/17 22:56, Stefano Stabellini wrote:
On Thu, 2 Feb 2017, Julien Grall wrote:
On 01/02/17 23:23, Stefano Stabellini wrote:
On Wed, 1 Feb 2017, Julien Grall wrote:
On 31/01/2017 23:49, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Julien Grall wrote:
On 03/01/17 23:29, St
On Wed, Feb 08, 2017 at 01:00:25PM -0500, Waiman Long wrote:
> As the vcpu_is_preempted() call is pretty costly compared with other
> checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
> are done at a reduce frequency of once every 256 iterations.
That's just disgusting.
On Wed, Feb 08, 2017 at 01:00:24PM -0500, Waiman Long wrote:
> It was found when running fio sequential write test with a XFS ramdisk
> on a 2-socket x86-64 system, the %CPU times as reported by perf were
> as follows:
>
> 71.27% 0.28% fio [k] down_write
> 70.99% 0.01% fio [k] call_rwsem_d
> > +static void cpu_fini_work(unsigned int cpu)
> > +{
> > +unsigned int socket = cpu_to_socket(cpu);
> > +
> > +if ( !socket_cpumask[socket] || cpumask_empty(socket_cpumask[socket]) )
>
> I fear I don't understand this.
>
> Looking at 65a399ac it says:
>
> +.notifier_call = cpu_cal
>
>
> * Altp2m for ARM
> - Sergej Proskurin
>
This was a GSoC project last summer that unfortunately didn't make the
merge window. I'll probably pick it up sometime in the future and get it
rebased but it is unlikely to happen for 4.9.
Tamas
___
Xen
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
On 01/30/2017 05:33 PM, Julien Grall wrote:
This email only tracks big items for xen.git tree. Please
On Wed, 2017-02-08 at 10:02 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 17:48, wrote:
> > Am I looking in the wrong places / misunderstood anything?
>
> Well, me having done the backports didn't imply me committing them
> right away; I wanted them to first undergo some testing.
>
Ok, right,
Hi Andrew,
On 03/02/17 20:44, Andrew Cooper wrote:
On 03/02/17 19:18, Julien Grall wrote:
@@ -260,16 +257,22 @@ int __init acpi_boot_table_init(void)
error = acpi_table_init();
if ( error )
{
-disable_acpi();
-return error;
+printk("%s: Unable to initializ
On 07/02/17 18:43, Andrew Cooper wrote:
> While adjusting these functions, use unsigned int rather than uint8_t for the
> loop variable, and fix the whitespace style.
>
> No functional change.
I think changing a variable from 8 to 64 bits might count as a
functional change; but anyway:
Reviewed-
On Wed, 2017-02-08 at 12:14 -0500, Boris Ostrovsky wrote:
> On 02/08/2017 11:05 AM, Joe Perches wrote:
> > On Wed, 2017-02-08 at 10:33 -0500, Boris Ostrovsky wrote:
> > > On 02/08/2017 06:33 AM, Joe Perches wrote:
> > > > This function error patch can be simplified, so do so.
> > > >
> > > > Remov
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
> (CC Konrad)
>
> Hi Oleksandr,
>
> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
> >
> > On 01/30/2017 05:33 PM, Julien Grall wrote:
> > > This email only tracks big items for xen.git tree. Please reply for
> > > items you
> > >
On 08/02/17 17:29, Tim Deegan wrote:
> At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>> nested p2m tables whenever the host p2m table changed. Unfortunately
>> in the process, it added a filter to p2m_flush_table()
On 08/02/17 18:06, George Dunlap wrote:
> On 08/02/17 13:20, Andrew Cooper wrote:
>> On 08/02/17 13:13, Jan Beulich wrote:
>> On 07.02.17 at 19:48, wrote:
Until the IPI has completed, other processors might be running on this
nested
p2m object. clear_domain_page() does not gua
On 08/02/17 13:20, Andrew Cooper wrote:
> On 08/02/17 13:13, Jan Beulich wrote:
> On 07.02.17 at 19:48, wrote:
>>> Until the IPI has completed, other processors might be running on this
>>> nested
>>> p2m object. clear_domain_page() does not guarantee to make 8-byte atomic
>>> updates, which
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
On 01/30/2017 05:33 PM, Julien Grall wrote:
This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingl
As the vcpu_is_preempted() call is pretty costly compared with other
checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
are done at a reduce frequency of once every 256 iterations.
Signed-off-by: Waiman Long
---
kernel/locking/mutex.c | 5 -
kernel/locking/rwsem-xadd.c
It was found when running fio sequential write test with a XFS ramdisk
on a 2-socket x86-64 system, the %CPU times as reported by perf were
as follows:
71.27% 0.28% fio [k] down_write
70.99% 0.01% fio [k] call_rwsem_down_write_failed
69.43% 1.18% fio [k] rwsem_down_write_failed
65.51%
Hi Wei,
On 30/01/17 15:45, Wei Liu wrote:
On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote:
[...]
I think it would be good to main two lists. One of "the stuff people
are working on overall", and "the subset of it intended/expected for the
forthcoming release".
Stuff will invaria
On 02/08/2017 07:20 PM, Andrew Cooper wrote:
> On 08/02/17 17:08, Razvan Cojocaru wrote:
>> On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
>>>
>>> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
>>> mailto:rcojoc...@bitdefender.com>> wrote:
>>>
>>> It is currently possible for the guest to lock
flight 105639 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> nested p2m tables whenever the host p2m table changed. Unfortunately
> in the process, it added a filter to p2m_flush_table() function so
> that the p2m would only be f
On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> Hi Tamas,
>
> On 08/02/17 16:40, Tamas K Lengyel wrote:
> >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> >mailto:edgar.igles...@xilinx.com>> wrote:
> >On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> >>
flight 105642 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105642/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed. Unfortunately
in the process, it added a filter to p2m_flush_table() function so
that the p2m would only be flushed if it was being used as a nested
p2m. This meant that the p2
On 08/02/17 17:08, Razvan Cojocaru wrote:
> On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
>> mailto:rcojoc...@bitdefender.com>> wrote:
>>
>> It is currently possible for the guest to lock when subscribing
>> to synchronous vm_events if
On Wed, Feb 8, 2017 at 9:58 AM, Julien Grall wrote:
> Hi Tamas,
>
> On 08/02/17 16:40, Tamas K Lengyel wrote:
>
>> On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
>> mailto:edgar.igles...@xilinx.com>> wrote:
>> On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
>> > On Tue
On 08/02/17 13:07, Jan Beulich wrote:
On 07.02.17 at 19:57, wrote:
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -599,4 +599,10 @@ static inline void filtered_flush_tlb_mask(uint32_t
>> tlbflush_timestamp)
>> }
>> }
>>
>> +static inline bool is_xen_fixed_mfn(mfn_t
On 02/08/2017 11:05 AM, Joe Perches wrote:
> On Wed, 2017-02-08 at 10:33 -0500, Boris Ostrovsky wrote:
>> On 02/08/2017 06:33 AM, Joe Perches wrote:
>>> This function error patch can be simplified, so do so.
>>>
>>> Remove fail: label and somewhat obfuscating, used once "error_path"
>>> function.
>
On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
>
>
> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> It is currently possible for the guest to lock when subscribing
> to synchronous vm_events if max_vcpus is larger than the
> number of
On 07/02/17 17:28, Roger Pau Monne wrote:
> There's nothing wrong with allowing the domain to perform DMA transfers to
> MMIO areas that it already can access from the CPU, and this allows us to
> remove the hack in set_identity_p2m_entry for PVH Dom0.
>
> Signed-off-by: Roger Pau Monné
> Reviewe
>>> On 08.02.17 at 08:31, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, February 06, 2017 11:38 PM
>>
>> >>> On 06.02.17 at 15:48, wrote:
>> > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
>> >> >
>> >> > >
>> >> > > >
>> >> > > > On 06.02.17 at 14:55, wrote:
On 02/08/2017 04:06 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 was being set from the max_memkb field o
flight 105633 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 17 guest-localmigrate/x10 fail REGR. vs. 105625
test-amd64-amd64-xl-
>>> On 08.02.17 at 17:48, wrote:
> On Fri, 2017-02-03 at 08:40 -0700, Jan Beulich wrote:
>> > > > > > On 17.01.17 at 18:26, wrote:
>> > > While I did manage to backport "xen: credit2: use the correct
>> > > scratch
>> > > cpumask" and "xen: credit2: fix shutdown/suspend when playing
>> > > with
>
And CC Zhangchen
On Wed, Feb 08, 2017 at 02:35:27PM +, Wei Liu wrote:
> Cc Yi Sun as well.
>
> Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
> time to split libxl.c so things are better organised. It's likely this
> series will go in before yours, so you will then nee
On 08/02/17 17:41, Jan Beulich wrote:
On 08.02.17 at 17:32, wrote:
>> Is it still appropriate to have the unmodified_drivers subdirectory in
>> Xen's git repository?
>>
>> I think it should be either moved to a separate repository or just
>> deleted.
>
> Having a separate repo for these few
Hi Tamas,
On 08/02/17 16:40, Tamas K Lengyel wrote:
On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
mailto:edgar.igles...@xilinx.com>> wrote:
On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall mailto:julien.gr...@arm.com>> wr
On Fri, 2017-02-03 at 08:40 -0700, Jan Beulich wrote:
> > > > > > On 17.01.17 at 18:26, wrote:
> > > While I did manage to backport "xen: credit2: use the correct
> > > scratch
> > > cpumask" and "xen: credit2: fix shutdown/suspend when playing
> > > with
> > > cpupools" also to 4.7, this one is e
On Wed, Feb 08, 2017 at 04:15:57PM +0800, Yi Sun wrote:
> This patch implements the Domain init/free and schedule flows.
>
> Signed-off-by: Yi Sun
Reviewed-by: Konrad Rzeszutek Wilk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
>>> On 08.02.17 at 17:32, wrote:
> Is it still appropriate to have the unmodified_drivers subdirectory in
> Xen's git repository?
>
> I think it should be either moved to a separate repository or just
> deleted.
Having a separate repo for these few files would seem overkill to
me. As to deleting
On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias wrote:
> On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> > On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall
> wrote:
> >
> > > Hi Tamas,
> > >
> > > On 07/02/2017 20:38, Tamas K Lengyel wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb
Is it still appropriate to have the unmodified_drivers subdirectory in
Xen's git repository?
I think it should be either moved to a separate repository or just
deleted. Having Linux kernel sources in the Xen repository seems to be
wrong.
Thoughts?
Juergen
__
On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
wrote:
> It is currently possible for the guest to lock when subscribing
> to synchronous vm_events if max_vcpus is larger than the
> number of available ring buffer slots. This patch no longer
> blocks already paused VCPUs, fixing the issue for thi
This run is configured for baseline tests only.
flight 68534 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-insta
On 08/02/17 10:02, Tim Deegan wrote:
> At 03:44 -0700 on 31 Jan (1485834259), Jan Beulich wrote:
> On 30.01.17 at 16:17, wrote:
>>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>>> nested p2m tables whenever the host p2m table changed. Unfortunately
>>> in the process, it
.snip..
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause
flight 105636 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105636/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
baseline version:
ovmf cc20411062137e5d820a3
On 08/02/17 17:12, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH 0/9] libxl: spolit up libxl.c"):
>> Okay, more precise wording:
>
> Thanks.
>
>> Changes are:
>> - moving functions into new or existing sources
>> - modification of Copyright comment
>
>> - made two functions non-static:
On Tue, Feb 7, 2017 at 11:48 PM, Razvan Cojocaru
wrote:
> On 02/08/2017 01:23 AM, Tamas K Lengyel wrote:
> >
> >
> > On Tue, Feb 7, 2017 at 1:41 PM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > On 02/07/2017 10:20 PM, Tamas K Lengyel wrote:
> > >
> > >
> >
On 08/02/17 16:11, Dario Faggioli wrote:
> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
>> Callers to libxl_cpupool_create() can either request a specific pool
>> id, or request that Xen do it for them. But at the moment, the
>> "automatic" selection is indicated by using a magic value,
1 - 100 of 255 matches
Mail list logo
