This run is configured for baseline tests only.
flight 75347 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75347/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2018年10月3日 0:03
> To: Peng Fan ; Stefano Stabellini
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: Question, How to share interrupt between Doms
>
> On 02/10/2018 09:32, Peng Fan
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-examine
testid reboot
Tree: freebsd git://github.com/freebsd/freebsd.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
flight 128351 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128351/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c0b1f749ef1304810ed4ea58ded65b7f41d79d3e
baseline version:
ovmf
On Wed, 1 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Introduce a new array to store the cmdline of each boot module. It is
> > separate from struct bootmodules. Remove the cmdline field from struct
> > boot_module. This way, kernels and
On Wed, 22 Aug 2018, Julien Grall wrote:
> On 16/08/18 20:21, Stefano Stabellini wrote:
> > On Mon, 13 Aug 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 01/08/18 00:28, Stefano Stabellini wrote:
> > > > Make vpl011 being able to be used without a userspace component in Dom0.
> > > >
At 17:56 +0100 on 03 Oct (1538589366), George Dunlap wrote:
> On 09/26/2018 08:04 AM, Jan Beulich wrote:
> > Looking at things again (in particular
> > the comment ahead of pagetable_dying()) I now actually wonder why
> > HVMOP_pagetable_dying is permitted to be called by other than a domain
> >
flight 128333 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-saverestore.2 fail
REGR. vs. 128084
On 02/10/18 11:14, Jan Beulich wrote:
> For (I hope) obvious reasons only the ones used at runtime get
> converted.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On 02/10/18 11:14, Jan Beulich wrote:
> Instead of loading a pointer at each use site, have a single runtime
> instance of struct genapic, copying into it from the individual
> instances. The individual instances can this way also be moved to .init
> (also adjust apic_probe[] at this occasion).
>
On 02/10/18 11:13, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 02/10/18 11:13, Jan Beulich wrote:
> @@ -1509,7 +1513,8 @@ static int lapic_load_regs(struct domain
> lapic_load_fixup(s);
>
> if ( hvm_funcs.process_isr )
> -hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
> +alternative_vcall(hvm_funcs.process_isr,
> +
On 02/10/18 11:12, Jan Beulich wrote:
> In a number of cases the targets of indirect calls get determined once
> at boot time. In such cases we can replace those calls with direct ones
> via our alternative instruction patching mechanism.
>
> Some of the targets (in particular the hvm_funcs ones)
flight 128347 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128347/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, 1 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Introduce an allocate_memory function able to allocate memory for DomUs
> > and map it at the right guest addresses, according to the guest memory
> > map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
> >
On 03/10/2018 16:34, Vitaly Kuznetsov wrote:
> Dave Hansen writes:
>
>> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
>>> It is more than just memmaps (e.g. forking udev process doing memory
>>> onlining also needs memory) but yes, the main idea is to make the
>>> onlining synchronous with
On 03/10/2018 16:24, Michal Hocko wrote:
> On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote:
> [...]
>>> As David said some of the memory cannot be onlined without further steps
>>> (e.g. when it is standby as David called it) and then I fail to see how
>>> eBPF help in any way.
>>
>> and also, we
On 03/10/2018 15:54, Michal Hocko wrote:
> On Tue 02-10-18 17:25:19, David Hildenbrand wrote:
>> On 02/10/2018 15:47, Michal Hocko wrote:
> [...]
>>> Zone imbalance is an inherent problem of the highmem zone. It is
>>> essentially the highmem zone we all loved so much back in 32b days.
>>> Yes the
On 09/26/2018 08:04 AM, Jan Beulich wrote:
On 25.09.18 at 18:22, wrote:
>> On 18/09/18 13:44, Jan Beulich wrote:
>> On 10.09.18 at 16:02, wrote:
Rather than unconditionally using vCPU 0, use the current vCPU if the
subject domain is the current one.
Signed-off-by:
On Wed, 1 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Add a new document to provide information on how to use dom0less related
> > features and their current limitations.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in
On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> > On 9/18/18 5:32 AM, George Dunlap wrote:
> > >
> > >> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Mon, Sep 17, 2018 at
>>> "DeGraaf, Daniel G" 10/02/18 7:39 PM >>>
>> From: Jan Beulich
>> >>> On 28.09.18 at 21:13, wrote:
>> > These entries are not always sorted by checkpolicy. Enforce the sorting
>> > (which can be done manually if using an unpatched checkpolicy) when
>> > loading the policy so that later uses
Dave Hansen writes:
> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
>> It is more than just memmaps (e.g. forking udev process doing memory
>> onlining also needs memory) but yes, the main idea is to make the
>> onlining synchronous with hotplug.
>
> That's a good theoretical concern.
>
> But,
This run is configured for baseline tests only.
flight 75343 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75343/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote:
[...]
> > As David said some of the memory cannot be onlined without further steps
> > (e.g. when it is standby as David called it) and then I fail to see how
> > eBPF help in any way.
>
> and also, we can fight till the end of days here trying to
On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
> It is more than just memmaps (e.g. forking udev process doing memory
> onlining also needs memory) but yes, the main idea is to make the
> onlining synchronous with hotplug.
That's a good theoretical concern.
But, is it a problem we need to solve
On Tue 02-10-18 17:25:19, David Hildenbrand wrote:
> On 02/10/2018 15:47, Michal Hocko wrote:
[...]
> > Zone imbalance is an inherent problem of the highmem zone. It is
> > essentially the highmem zone we all loved so much back in 32b days.
> > Yes the movable zone doesn't have any addressing
flight 128331 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128331/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128304
test-armhf-armhf-libvirt-raw 13
Michal Hocko writes:
> On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote:
>> David Hildenbrand writes:
>>
>> > On 02/10/2018 15:47, Michal Hocko wrote:
>> ...
>> >>
>> >> Why do you need a generic hotplug rule in the first place? Why don't you
>> >> simply provide different set of rules for
On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote:
> David Hildenbrand writes:
>
> > On 02/10/2018 15:47, Michal Hocko wrote:
> ...
> >>
> >> Why do you need a generic hotplug rule in the first place? Why don't you
> >> simply provide different set of rules for different usecases? Let users
> >>
flight 128339 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128339/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd a16e14a2bb879c082d379f9ca2f201e993960b85
baseline version:
freebsd
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of
On Tue, Oct 02, 2018 at 06:36:14PM +0200, Roger Pau Monne wrote:
> Instead of just doing it for the BSP. This requires storing the
> maximum number of possible vCPUs in xc_dom_image.
>
> This has been a latent bug so far because PVH doesn't yet support
> pci-passthrough, so the effective memory
David Hildenbrand writes:
> On 02/10/2018 15:47, Michal Hocko wrote:
...
>>
>> Why do you need a generic hotplug rule in the first place? Why don't you
>> simply provide different set of rules for different usecases? Let users
>> decide which usecase they prefer rather than try to be clever
On Thu, Sep 27, 2018 at 10:58:54AM +0300, Razvan Cojocaru wrote:
> Currently there is a subop for setting the memaccess of a page, but not
> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
> functionality.
>
> Both altp2m get/set mem access functions use the struct
>
On Wed, 2018-10-03 at 12:53 +0200, Juergen Gross wrote:
> On 02/10/2018 17:49, George Dunlap wrote:
> > Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> > output of xl list -l") added scheduling parameters to the set of
> > information collected by
Hello,
A bug has recently been discovered internally, where a 4.14 dom0 was
observed to be doing this:
(XEN) [ 16.035377] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR 001b
from 0xfee00d00 to 0xfee00100
(XEN) [ 16.035392] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR
On Wed, Oct 3, 2018 at 12:29 PM Wei Liu wrote:
>
> On Wed, Oct 03, 2018 at 12:02:24PM +0100, George Dunlap wrote:
> > On Tue, Oct 2, 2018 at 3:20 PM Juergen Gross wrote:
> > >
> > > Today the domain config info contains the cpupool name the domain was
> > > started in only if the cpupool was
On Wed, Oct 03, 2018 at 12:02:24PM +0100, George Dunlap wrote:
> On Tue, Oct 2, 2018 at 3:20 PM Juergen Gross wrote:
> >
> > Today the domain config info contains the cpupool name the domain was
> > started in only if the cpupool was specified at domain creation. Moving
> > the domain to another
On Wed, Oct 03, 2018 at 01:07:30PM +0200, Juergen Gross wrote:
> On 03/10/2018 13:00, Wei Liu wrote:
> > On Wed, Sep 26, 2018 at 07:30:38PM +0200, Dario Faggioli wrote:
> >> On Fri, 2018-09-21 at 09:52 +0100, Wei Liu wrote:
> >>> On Fri, Sep 21, 2018 at 07:23:23AM +0200, Juergen Gross wrote:
>
On Wed, Sep 26, 2018 at 01:42:09AM -0600, Jan Beulich wrote:
> Having noticed that VMLOAD alone is about as fast as a single of the
> involved WRMSRs, I thought it might be a reasonable idea to also use it
> for PV. Measurements, however, have shown that an actual improvement can
> be achieved
On 03/10/2018 13:00, Wei Liu wrote:
> On Wed, Sep 26, 2018 at 07:30:38PM +0200, Dario Faggioli wrote:
>> On Fri, 2018-09-21 at 09:52 +0100, Wei Liu wrote:
>>> On Fri, Sep 21, 2018 at 07:23:23AM +0200, Juergen Gross wrote:
On 20/09/18 18:06, Wei Liu wrote:
>
> It appears that the
On Tue, Oct 2, 2018 at 3:20 PM Juergen Gross wrote:
>
> Today the domain config info contains the cpupool name the domain was
> started in only if the cpupool was specified at domain creation. Moving
> the domain to another cpupool later won't change that information.
>
> Correct that by
On 10/3/18 1:56 PM, Сергей wrote:
>> No yet, we're working on it.
> Could You point me to the branch with Your patches please? I Could not find
> it in https://xenbits.xen.org/gitweb/?p=xen.git
There's no public branch with my patches, I'm working locally. The
original patch has now split into
On Thu, Sep 27, 2018 at 07:58:39AM +0200, Juergen Gross wrote:
> On 21/09/18 10:52, Wei Liu wrote:
> > On Fri, Sep 21, 2018 at 07:23:23AM +0200, Juergen Gross wrote:
> >> On 20/09/18 18:06, Wei Liu wrote:
> >>> On Wed, Sep 19, 2018 at 07:58:50PM +0200, Juergen Gross wrote:
>
> Did you
> No yet, we're working on it.
Could You point me to the branch with Your patches please? I Could not find it
in https://xenbits.xen.org/gitweb/?p=xen.git
With best regards
Sergey Kovalev.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 02/10/2018 17:49, George Dunlap wrote:
> Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> output of xl list -l") added scheduling parameters to the set of
> information collected by libxl_retrieve_domain_configuration(), in
> order to report that information in `xl list -l`.
On 10/02/2018 04:49 PM, George Dunlap wrote:
> Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> output of xl list -l") added scheduling parameters to the set of
> information collected by libxl_retrieve_domain_configuration(), in
> order to report that information in `xl list
On Mon, Oct 01, 2018 at 07:57:21PM +0100, Julien Grall wrote:
> Currently, the toolstack is considering Arm guest always PV. However,
> they are very similar to PVH because HW virtualization extension are used
> and QEMU is not started. So switch Arm guest type to PVH.
>
> To keep compatibility
On 10/3/18 12:00 AM, Paul Durrant wrote:
> This patch modifies the methods in struct iommu_ops to use type-safe DFN
> and MFN. This follows on from the prior patch that modified the functions
> exported in xen/iommu.h.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Wei Liu
> Reviewed-by: Kevin
On Mon, Oct 01, 2018 at 07:57:19PM +0100, Julien Grall wrote:
> The PV fields kernel, ramdisk, cmdline are only there for compatibility
> with old toolstack. Instead of manually copying them over to there new
> field, use the deprecated_by attribute in the IDL.
>
> Suggested-by: Roger Pau Monné
Scrubbing RAM during boot may take a long time on machines with lots
of RAM. Add 'idle' option which marks all pages dirty initially so they
would eventually be scrubbed in idle-loop on every online CPU.
Performance of idle-loop scrubbing is worse than bootscrub but it's
guaranteed that the
Hi,
On 10/3/18 12:00 AM, Paul Durrant wrote:
> ...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
> (rather than the MMU) and hence used for DMA address translation.
>
> This patch is a largely cosmetic change that substitutes the terms 'gfn'
> and 'gaddr' for 'dfn' and
Wei Liu writes ("Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool parameter
to xl migrate"):
> On Tue, Oct 02, 2018 at 05:08:27PM +0200, Juergen Gross wrote:
> > And TBH: I consider the -C option being quite dangerous. While I can
> > understand why it is present it is still a rather hacky
flight 128338 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128338/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 54ec59f6b0b363c34cf1864d5214a05e35ea75ee
baseline version:
xen
flight 75342 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75342/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 10/02/2018 11:03 AM, Omkar Bolla wrote:
Hi,
Thanks,
Basic state change is working now, after using above script.
As I said, I want to share buffer between two domains.
Could you please suggest outlines, how can I share buffer between 2
domains(Guest and Host)?
My question on a previous
On Tue, Oct 02, 2018 at 03:43:37PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool
> parameter to xl migrate"):
> > Is this the wisest way to extend the interface? We already have -C to
> > specify new configuration, and only have 26*2 short
On Tue, Oct 02, 2018 at 05:08:27PM +0200, Juergen Gross wrote:
> On 02/10/2018 16:42, Andrew Cooper wrote:
> > On 02/10/18 15:19, Juergen Gross wrote:
> >> Add an option to specify the cpupool on the target machine when doing
> >> a migration of a domain. Currently a domain is always migrated to
flight 128324 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128291
test-armhf-armhf-libvirt 14
On Tue, Oct 02, 2018 at 04:19:34PM +0200, Juergen Gross wrote:
> Add an option to specify the cpupool on the target machine when doing
> a migration of a domain. Currently a domain is always migrated to the
> cpupool with the same name as on the source machine.
>
> Specifying "-c " will migrate
On Tue, Oct 02, 2018 at 04:19:33PM +0200, Juergen Gross wrote:
> Today the domain config info contains the cpupool name the domain was
> started in only if the cpupool was specified at domain creation. Moving
> the domain to another cpupool later won't change that information.
>
> Correct that by
On Tue, Oct 02, 2018 at 05:44:15AM -0600, Jan Beulich wrote:
> ... and try to improve readability of some of the output.
>
> 1: drop bogus casts from dump_cpu()
> 2: drop bogus casts from dump_lapic_regs()
> 3: drop bogus casts from dump_hpet()
> 4: drop bogus casts from dump_mtrr()
Acked-by:
63 matches
Mail list logo
