flight 137099 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137099/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 137063
test-armhf-armhf-libvirt-raw 13
On 30/05/2019 07:18, Petre Pircalabu wrote:
> This patchset adds a new mechanism of sending synchronous vm_event
> requests and handling vm_event responses without using a ring.
> As each synchronous request pauses the vcpu until the corresponding
> response is handled, it can be stored in a
On 30/05/2019 07:18, Petre Pircalabu wrote:
> The vm_event_domain members are not accessed outside vm_event.c so it's
> better to hide de implementation details.
>
> Signed-off-by: Petre Pircalabu
Acked-by: Andrew Cooper
Are there any files which now no longer need to include sched.h ?
On 30/05/2019 07:18, Petre Pircalabu wrote:
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 3505589..1dd3e48 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -277,7 +277,7 @@ void vm_event_put_request(struct domain *d,
> RING_IDX req_prod;
>
On 30/05/2019 07:18, Petre Pircalabu wrote:
> vm_event_get_response, vm_event_resume, and vm_event_mark_and_pause are
> used only in xen/common/vm_event.c.
>
> Signed-off-by: Petre Pircalabu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
On 30/05/2019 07:18, Petre Pircalabu wrote:
> diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
> index ea10366..3b1018b 100644
> --- a/tools/libxc/xc_vm_event.c
> +++ b/tools/libxc/xc_vm_event.c
> @@ -23,29 +23,54 @@
> #include "xc_private.h"
>
> int
flight 137095 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137095/
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. 129313
Tests which are
On 31/05/2019 16:00, Stefano Stabellini wrote:
> Introduce two global parameters to disable debug registers trapping and
> perf counters trapping. They are only safe to use in static partitiong
> scenarios where sched=null is used -- vcpu cannot be migrated from one
> pcpu to the next.
>
>
On 30/05/2019 07:18, Petre Pircalabu wrote:
> Modified xc_mem_paging_enable to use directly xc_vm_event_enable and
> moved the ring_page handling from client to libxc (xenpaging).
>
> Restricted vm_event_control usage only to simplest domctls which do
> not expect any return values and change
Introduce two global parameters to disable debug registers trapping and
perf counters trapping. They are only safe to use in static partitiong
scenarios where sched=null is used -- vcpu cannot be migrated from one
pcpu to the next.
Introduce a new simple umbrella command line option
On 30/05/2019 18:58, Baodong Chen wrote:
> keyhandler mainly used for debug usage by developers which can dump
> xen module(eg. timer, scheduler) status at runtime by input
> character from console.
>
> Signed-off-by: Baodong Chen
What is the motivation here? I don't have a specific objection
On 31/05/2019 12:18, YOUNG, MICHAEL A. wrote:
> On Tue, 16 Apr 2019, M A Young wrote:
>
>> On Tue, 16 Apr 2019, Andrew Cooper wrote:
>>
>>> From the log:
>>>
>>> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 erro
>>> r:0 in ld-2.29.so[7f797dc61000+21000]
>>>
>>>
>>> Can
On 31/05/2019 02:52, Jan Beulich wrote:
> According to Linux commit 0136611c62 ("optimize hweight64 for x86_64")
> this is a further improvement over the variant using only bitwise
> operations. It's also a slight further code size reduction.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan
On 31/05/2019 02:51, Jan Beulich wrote:
> Algorithmically this gets us in line with current Linux, where the same
> change did happen about 13 years ago. See in particular Linux commits
> f9b4192923 ("bitops: hweight() speedup") and 0136611c62 ("optimize
> hweight64 for x86_64").
>
> Kconfig
On 31/05/2019 02:54, Jan Beulich wrote:
> This is faster than using the software implementation, and the insn is
> available on all half-way recent hardware. Therefore convert
> generic_hweight() to out-of-line functions (without affecting Arm)
> and use alternatives patching to replace the
flight 137096 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137096/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5a9e23ceb991f3bd0eea74d6b67f9102f65ea6bc
baseline version:
ovmf
From: Colin King
Date: Thu, 30 May 2019 20:04:38 +0100
> From: Colin Ian King
>
> The variable err is assigned with the value -ENOMEM that is never
> read and it is re-assigned a new value later on. The assignment is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
>
flight 137117 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137117/
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
flight 137094 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137094/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 136516
On Fri, 31 May 2019, Julien Grall wrote:
> Hi Andrii,
>
> On 30/05/2019 17:12, Andrii Anisov wrote:
> > On 29.05.19 18:32, Julien Grall wrote:
> > > It would have been nice to at least fix up the commit message with the
> > > typoes (and rewording) I mentioned in my previous e-mail.
> > > Your
> On May 31, 2019, at 4:48 AM, Juergen Gross wrote:
>
> On 31/05/2019 08:36, Nadav Amit wrote:
>>
>> --- a/arch/x86/include/asm/paravirt_types.h
>> +++ b/arch/x86/include/asm/paravirt_types.h
>> @@ -211,6 +211,12 @@ struct pv_mmu_ops {
>> void (*flush_tlb_user)(void);
>> void
On Tue, 16 Apr 2019, M A Young wrote:
> On Tue, 16 Apr 2019, Andrew Cooper wrote:
>
>> From the log:
>>
>> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 erro
>> r:0 in ld-2.29.so[7f797dc61000+21000]
>>
>>
>> Can you disassemble ld-2.29.so and find out what that
On 31/05/2019 06:06, Jan Beulich wrote:
On 31.05.19 at 13:53, wrote:
>> The "allbutself" cpumask in stop_machine_run() is not needed. Instead
>> of allocating it on the stack it can easily be avoided.
>>
>> Signed-off-by: Juergen Gross
> Reviewed-by: Jan Beulich
LGTM. Acked-by: Andrew
The pull request you sent on Fri, 31 May 2019 15:56:03 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.2b-rc3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8164c5719b864da3bcfee97ad8af8cfd7ee5ad8c
Thank you!
--
Deet-doot-dot,
On 31/05/2019 18:25, Andre Przywara wrote:
On Tue, 28 May 2019 18:07:19 +0100
Julien Grall wrote:
[ ... ]
While looking at the code, I noticed that in the new vgic vgic_get_irq()
looks unsafe to be called with interrupt unmasked. This is because one
of the callee (vgic_get_lpi()) takes a
Hi,
Title: s/upto/ I think?
Also how about: "Properly configure stage-2 for 42-bit PA system".
On 30/05/2019 08:59, Vishnu Pajjuri OS wrote:
XEN configures stage-2 page table to expose 40 bits of IPA
(Intermediate Physical Address) bits for systems with 42 bits of PA
I think you want to
On Fri, 31 May 2019 18:16:52 +0100
Julien Grall wrote:
> Hi,
>
> On 30/05/2019 17:14, Andrii Anisov wrote:
> >
> >
> > On 29.05.19 18:32, Julien Grall wrote:
> >>> BTW, do you hear about plans for the new vgic? Some time ago it was said
> >>> that
> >>> new vgic implementation going to
On Fri, 31 May 2019, Julien Grall wrote:
> Hi Jan,
>
> On 31/05/2019 11:46, Jan Beulich wrote:
> > > > > On 31.05.19 at 12:34, wrote:
> > > No it was a more generic statement on the stance "It already exists in
> > > Xen so it is fine to spread them a bit more".
> >
> > Oh, I see. Of course I'm
Hi Andrew,
On 17/05/2019 19:58, Andrew Cooper wrote:
Reflow the ZynqMP message for grepability, and fix the omission of a newline.
Signed-off-by: Andrew Cooper
Regardless Jan's comment:
Reviewed-by: Julien Grall
I will let Jan/You to commit the patch.
Cheers,
---
CC: Jan Beulich
CC:
Hi,
On 30/05/2019 17:14, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
BTW, do you hear about plans for the new vgic? Some time ago it was said that
new vgic implementation going to replace the old one, and optimizing the old
is worthless. But as I see, there are no updates
On 31/05/2019 02:35, Jan Beulich wrote:
> A couple of adjustments are needed to code checking for dom_cow, but
> since there are pretty few it is probably better to adjust those than
> to set up and keep around a never used domain.
>
> Take the opportunity and tighten a BUG_ON() in
Hi Andrii,
On 30/05/2019 17:12, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
It would have been nice to at least fix up the commit message with the typoes
(and rewording) I mentioned in my previous e-mail.
Your commit message needs to explained why this is fine to keep the
On 31/05/2019 17:52, Dario Faggioli wrote:
> On Tue, 2019-05-28 at 12:33 +0200, Juergen Gross wrote:
>> Instead of having a full blown scheduler running for the free cpus
>> add a very minimalistic scheduler for that purpose only ever
>> scheduling
>> the related idle vcpu. This has the big
flight 137093 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 137033
On 31/05/2019 08:52, Jan Beulich wrote:
> Don't do this once per IOMMU, nor after setting up the IOMMU interrupt
> (which will want to schedule this tasklet). In fact it can be
> initialized at build time.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 31/05/2019 08:59, Jan Beulich wrote:
>
>>> +#ifdef CONFIG_HAS_PCI
>>> +INIT_LIST_HEAD(_xen->arch.pdev_list);
>>> +#endif
>> The position of this identifies that we've got obviously got bugs
>> (perhaps latent) elsewhere, seeing as other special domains don't get
>> working constructs such
>>> On 31.05.19 at 17:32, wrote:
> On 31/05/2019 02:35, Jan Beulich wrote:
>> @@ -516,6 +521,36 @@ struct domain *domain_create(domid_t dom
>> return ERR_PTR(err);
>> }
>>
>> +void __init setup_special_domains(void)
>> +{
>> +/*
>> + * Initialise our DOMID_XEN domain.
>> + *
Don't do this once per IOMMU, nor after setting up the IOMMU interrupt
(which will want to schedule this tasklet). In fact it can be
initialized at build time.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -31,7 +31,8
On Tue, 2019-05-28 at 12:33 +0200, Juergen Gross wrote:
> Instead of having a full blown scheduler running for the free cpus
> add a very minimalistic scheduler for that purpose only ever
> scheduling
> the related idle vcpu. This has the big advantage of not needing any
> per-cpu, per-domain or
Hi Ian,
On 30/05/2019 17:51, Ian Jackson wrote:
drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of
`dma_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
This is fixed by
firmware: qcom_scm: Use proper types for dma mappings
but this is
On 31/05/2019 02:35, Jan Beulich wrote:
> @@ -516,6 +521,36 @@ struct domain *domain_create(domid_t dom
> return ERR_PTR(err);
> }
>
> +void __init setup_special_domains(void)
> +{
> +/*
> + * Initialise our DOMID_XEN domain.
> + * Any Xen-heap pages that we will allow to be
On May 31, 2019 10:41:16 AM EDT, Juergen Gross wrote:
>On 06/05/2019 10:11, Juergen Gross wrote:
>> On 03/05/2019 17:04, Roger Pau Monne wrote:
>>> There's no reason to request physically contiguous memory for those
>>> allocations.
>>>
>>> Reported-by: Ian Jackson
>>> Signed-off-by: Roger Pau
On 06/05/2019 10:11, Juergen Gross wrote:
> On 03/05/2019 17:04, Roger Pau Monne wrote:
>> There's no reason to request physically contiguous memory for those
>> allocations.
>>
>> Reported-by: Ian Jackson
>> Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Juergen Gross
Jens, are you going to
flight 137090 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
> -Original Message-
[snip]
> >> > --- a/xen/include/xen/pci.h
> >> > +++ b/xen/include/xen/pci.h
> >> > @@ -75,6 +75,9 @@ struct pci_dev {
> >> > struct list_head alldevs_list;
> >> > struct list_head domain_list;
> >> >
> >> > +struct list_head grpdevs_list;
> >>
> >> Does
On Tue, 2019-05-28 at 13:58 +0200, Juergen Gross wrote:
> On 28/05/2019 13:47, Jan Beulich wrote:
> > > > > On 28.05.19 at 12:33, wrote:
> > > Instead of having a full blown scheduler running for the free
> > > cpus
> > > add a very minimalistic scheduler for that purpose only ever
> > >
>>> On 31.05.19 at 15:55, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 15 May 2019 15:18
>>
>> >>> On 08.05.19 at 15:24, wrote:
>> > +id = ops->get_device_group_id(pdev->seg, pdev->bus, pdev->devfn);
>> > +grp = get_iommu_group(id);
>>
>> I don't think solitary
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 May 2019 15:18
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu
> ; George Dunlap ; Ian Jackson
> ;
> Stefano Stabellini ; xen-devel
> ; Konrad
> Rzeszutek Wilk ; Tim (Xen.org)
> Subject:
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.2b-rc3-tag
xen: fixes for 5.2-rc3
It contains one minor cleanup patch and a fix for handling of live
migration when running as Xen guest.
Thanks.
Juergen
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 May 2019 09:45
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap
> ; Andrew Cooper ; Ian
> Jackson
> ; Tim (Xen.org) ; Julien Grall
> ; Jan
>
On Fri, 2019-05-31 at 10:26 +, George Dunlap wrote:
> > On May 30, 2019, at 3:15 PM, Andrii Anisov > > wrote:
> >
> > From: Andrii Anisov
> >
> > The structure member last_run_time is used by credit scheduler
> > only.
> > So move it from a generic vcpu structure to the credit scheduler
>
Hi Jan,
On 31/05/2019 11:46, Jan Beulich wrote:
On 31.05.19 at 12:34, wrote:
No it was a more generic statement on the stance "It already exists in
Xen so it is fine to spread them a bit more".
Oh, I see. Of course I'm making remarks when what's in the tree is
bad (as per e.g. coding style,
>>> On 31.05.19 at 14:58, wrote:
>> On May 31, 2019, at 12:10 PM, Jan Beulich wrote:
> On 30.05.19 at 12:17, wrote:
>>> Default: enabled.
>>> Can be disabled for smaller code footprint.
>>
>> But you're aware that we're, for now at least, trying to limit the
>> number of independently
>>> On 31.05.19 at 13:53, wrote:
> The "allbutself" cpumask in stop_machine_run() is not needed. Instead
> of allocating it on the stack it can easily be avoided.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with one further remark:
> --- a/xen/common/stop_machine.c
> +++
flight 137109 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137109/
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
flight 137067 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858
> On May 31, 2019, at 12:10 PM, Jan Beulich wrote:
>
On 30.05.19 at 12:17, wrote:
>> Default: enabled.
>> Can be disabled for smaller code footprint.
>
> But you're aware that we're, for now at least, trying to limit the
> number of independently selectable config options? Ones
The "allbutself" cpumask in stop_machine_run() is not needed. Instead
of allocating it on the stack it can easily be avoided.
Signed-off-by: Juergen Gross
---
xen/common/stop_machine.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/xen/common/stop_machine.c
On 31/05/2019 08:36, Nadav Amit wrote:
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before it can be
On 31/05/2019 04:02, Konrad Rzeszutek Wilk wrote:
> On 5/30/19 8:16 AM, Ben Hutchings wrote:
>> I'm looking at CVE-2015-8553 which is fixed by:
>>
>> commit 7681f31ec9cdacab4fd10570be924f2cef6669ba
>> Author: Konrad Rzeszutek Wilk
>> Date: Wed Feb 13 18:21:31 2019 -0500
>>
>> xen/pciback:
On 30/05/2019 14:46, Boris Ostrovsky wrote:
> On 5/30/19 5:04 AM, Christoph Hellwig wrote:
>> Please don't add your private flag to page-flags.h. The whole point of
>> the private flag is that you can use it in any way you want withou
>> touching the common code.
>
>
> There is already a bunch
>>> On 31.05.19 at 12:55, wrote:
> On 5/31/19 3:46 AM, Baodong Chen wrote:
>> --- a/xen/include/xen/cpu.h
>> +++ b/xen/include/xen/cpu.h
>> @@ -10,8 +10,8 @@ bool_t get_cpu_maps(void);
>> void put_cpu_maps(void);
>>
>> /* Safely perform CPU hotplug and update cpu_online_map, etc. */
>>
>>> On 31.05.19 at 12:55, wrote:
> osstest service owner writes ("[xen-4.7-testing test] 137065: regressions -
> FAIL"):
>> flight 137065 xen-4.7-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/137065/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are
>>> On 30.05.19 at 12:17, wrote:
> Default: enabled.
> Can be disabled for smaller code footprint.
But you're aware that we're, for now at least, trying to limit the
number of independently selectable config options? Ones depending
on EXPERT are sort of an exception in certain cases.
> ---
osstest service owner writes ("[xen-4.7-testing test] 137065: regressions -
FAIL"):
> flight 137065 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137065/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
Hi,
On 5/31/19 3:46 AM, Baodong Chen wrote:
Signed-off-by: Baodong Chen
---
xen/common/cpu.c | 10 --
xen/include/xen/cpu.h | 4 ++--
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index f388d89..a526b55 100644
---
On 31/05/2019 03:58, Baodong Chen wrote:
> keyhandler mainly used for debug usage by developers which can dump
> xen module(eg. timer, scheduler) status at runtime by input
> character from console.
>
> Signed-off-by: Baodong Chen
> ---
> xen/arch/arm/gic.c | 2 ++
>
Hi,
On 5/31/19 4:18 AM, Baodong Chen wrote:
Thus, sizeof(struct cpupool) will save 8 bytes for 64-bit system.
I am happy with the change, although AFAIK cpupool is not instantiated
that often. Are you planning to have more instantiation of it?
Cheers,
Signed-off-by: Baodong Chen
---
>>> On 31.05.19 at 12:34, wrote:
> No it was a more generic statement on the stance "It already exists in
> Xen so it is fine to spread them a bit more".
Oh, I see. Of course I'm making remarks when what's in the tree is
bad (as per e.g. coding style, or if not mentioned there than in my
On Fri, 2019-05-31 at 09:58 +0800, Baodong Chen wrote:
> keyhandler mainly used for debug usage by developers which can dump
> xen module(eg. timer, scheduler) status at runtime by input
> character from console.
>
> Signed-off-by: Baodong Chen
> ---
> --- a/xen/common/Kconfig
> +++
Hi Jan,
On 5/31/19 11:31 AM, Jan Beulich wrote:
On 31.05.19 at 12:10, wrote:
On 5/31/19 11:03 AM, Jan Beulich wrote:
On 31.05.19 at 11:52, wrote:
On 5/31/19 10:49 AM, Jan Beulich wrote:
On 31.05.19 at 11:42, wrote:
On 5/31/19 10:35 AM, Jan Beulich wrote:
--- a/xen/include/xen/mm.h
+++
osstest service owner writes ("[xen-4.6-testing test] 137064: regressions -
FAIL"):
> flight 137064 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137064/
>
> Regressions :-(
This is all pretty bad but I think it is mostly new tests in XTF,
incompatibility with
>>> On 29.05.19 at 18:13, wrote:
> There is a bug in llvm that needs to be fixed before switching to use
> the alternative assembly macros in inline assembly call sites.
> Therefore alternative_callN using inline assembly to generate the
> alternative patch sites should be using the ALTERNATIVE C
>>> On 31.05.19 at 12:10, wrote:
> On 5/31/19 11:03 AM, Jan Beulich wrote:
> On 31.05.19 at 11:52, wrote:
>>> On 5/31/19 10:49 AM, Jan Beulich wrote:
>>> On 31.05.19 at 11:42, wrote:
> On 5/31/19 10:35 AM, Jan Beulich wrote:
>> --- a/xen/include/xen/mm.h
>> +++
> On May 30, 2019, at 3:15 PM, Andrii Anisov wrote:
>
> From: Andrii Anisov
>
> The structure member last_run_time is used by credit scheduler only.
> So move it from a generic vcpu structure to the credit scheduler private
> vcpu definition.
This seems like a useful change, and the commit
Hi,
Missing commit message here.
On 5/31/19 3:35 AM, Baodong Chen wrote:
Signed-off-by: Baodong Chen
---
xen/common/notifier.c | 25 ++---
xen/include/xen/notifier.h | 21 +++--
2 files changed, 21 insertions(+), 25 deletions(-)
diff --git
On Fri, 2019-05-31 at 14:31 +0800, Baodong Chen wrote:
> when 'periodic_period' is zero, there is no need to initialize 'now'.
>
> Signed-off-by: Baodong Chen
> ---
> xen/common/schedule.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Acked-by: Dario Faggioli
Regards
--
Dario
Hi Jan,
On 5/31/19 11:03 AM, Jan Beulich wrote:
On 31.05.19 at 11:52, wrote:
On 5/31/19 10:49 AM, Jan Beulich wrote:
On 31.05.19 at 11:42, wrote:
On 5/31/19 10:35 AM, Jan Beulich wrote:
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -644,6 +644,9 @@ static inline void
>>> On 31.05.19 at 12:03, wrote:
> On 5/31/19 10:35 AM, Jan Beulich wrote:
>> --- a/xen/include/xen/domain.h
>> +++ b/xen/include/xen/domain.h
>> @@ -5,6 +5,7 @@
>> #include
>>
>> #include
>> +
>
> Without an explanation in the commit message, this looks like a spurious
> change.
Oh,
>>> On 31.05.19 at 11:52, wrote:
> On 5/31/19 10:49 AM, Jan Beulich wrote:
> On 31.05.19 at 11:42, wrote:
>>> On 5/31/19 10:35 AM, Jan Beulich wrote:
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -644,6 +644,9 @@ static inline void filtered_flush_tlb_ma
Hi Jan,
The Arm code looks good to me. I have few comments regarding the common
changes.
On 5/31/19 10:35 AM, Jan Beulich wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -71,6 +71,11 @@ domid_t hardware_domid __read_mostly;
integer_param("hardware_dom", hardware_domid);
flight 137080 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Therefore convert
generic_hweight() to out-of-line functions (without affecting Arm)
and use alternatives patching to replace the function calls.
Suggested-by: Andrew Cooper
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant using only bitwise operations on at least some hardware, and no
worse on other.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
RFC: To be honest I'm not
Hi,
On 5/31/19 10:49 AM, Jan Beulich wrote:
On 31.05.19 at 11:42, wrote:
On 5/31/19 10:35 AM, Jan Beulich wrote:
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -644,6 +644,9 @@ static inline void filtered_flush_tlb_ma
/* Private domain structs for DOMID_XEN, DOMID_IO, etc.
According to Linux commit 0136611c62 ("optimize hweight64 for x86_64")
this is a further improvement over the variant using only bitwise
operations. It's also a slight further code size reduction.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Kconfig
+++
Algorithmically this gets us in line with current Linux, where the same
change did happen about 13 years ago. See in particular Linux commits
f9b4192923 ("bitops: hweight() speedup") and 0136611c62 ("optimize
hweight64 for x86_64").
Kconfig changes for actually setting HAVE_FAST_MULTIPLY will
>>> On 31.05.19 at 11:42, wrote:
> On 5/31/19 10:35 AM, Jan Beulich wrote:
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -644,6 +644,9 @@ static inline void filtered_flush_tlb_ma
>>
>> /* Private domain structs for DOMID_XEN, DOMID_IO, etc. */
>> extern struct domain
1: bitops: speed up hweight()
2: x86: further speed-up to hweight{32,64}()
3: RFC: Arm64: further speed-up to hweight{32,64}()
4: x86: use POPCNT for hweight() when available
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi Jan,
On 5/31/19 10:35 AM, Jan Beulich wrote:
A couple of adjustments are needed to code checking for dom_cow, but
since there are pretty few it is probably better to adjust those than
to set up and keep around a never used domain.
Take the opportunity and tighten a BUG_ON() in
On Fri, 31 May 2019 10:12:03 +0100,
"Raslan, KarimAllah" wrote:
>
> On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote:
> > On 17.05.19 17:41, Sironi, Filippo wrote:
> > >
> > > >
> > > > On 16. May 2019, at 15:50, Graf, Alexander wrote:
> > > >
> > > > On 14.05.19 08:16, Filippo Sironi
A couple of adjustments are needed to code checking for dom_cow, but
since there are pretty few it is probably better to adjust those than
to set up and keep around a never used domain.
Take the opportunity and tighten a BUG_ON() in emul-priv-op.c:read_cr().
(Arguably this perhaps shouldn't be a
Split out this mostly arch-independent code into a common-code helper
function. (This does away with Arm's arch_init_memory() altogether.)
On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
("x86/ACPI: also parse AMD IOMMU tables early") only appeared to work
fine - it's
On 31.05.19 11:12, Raslan, KarimAllah wrote:
On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote:
On 17.05.19 17:41, Sironi, Filippo wrote:
On 16. May 2019, at 15:50, Graf, Alexander wrote:
On 14.05.19 08:16, Filippo Sironi wrote:
Start populating /sys/hypervisor with KVM entries when
Patch 1 fixes a really bad bug of mine, and while at it I thought I
would carry out the other recently noticed work item here right
away.
1: adjust special domain creation (and call it earlier on x86)
2: dom_cow is needed for mem-sharing only
Jan
Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
often for relatively simple leaf functions. (To give a specific example,
the case I've run into this with is _pci_hide_device() and gcc 8.
Interestingly the even more simple neighboring iommu_has_feature() does
get a frame
Nothing (afaics) guarantees that the original frame's stack pointer
points at readable memory. Avoid a (likely nested) crash by attaching
exception recovery to the read (making it a single read at the same
time). Don't even invoke _show_trace() in case of a non-readable top
slot.
Signed-off-by:
>>> On 30.05.19 at 10:59, wrote:
>>
>>> +return false;
>>> +
>>> +rc = hvmemul_linear_to_phys(gla, , bytes, , pfec, );
>>
>> As said before - I don't think it's a good idea to do the page walk
>> twice: This and the pre-existing one can easily return different
>> results.
>
> What
On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote:
> On 17.05.19 17:41, Sironi, Filippo wrote:
> >
> > >
> > > On 16. May 2019, at 15:50, Graf, Alexander wrote:
> > >
> > > On 14.05.19 08:16, Filippo Sironi wrote:
> > > >
> > > > Start populating /sys/hypervisor with KVM entries when
On 17.05.19 17:41, Sironi, Filippo wrote:
On 16. May 2019, at 15:50, Graf, Alexander wrote:
On 14.05.19 08:16, Filippo Sironi wrote:
Start populating /sys/hypervisor with KVM entries when we're running on
KVM. This is to replicate functionality that's available when we're
running on Xen.
1 - 100 of 110 matches
Mail list logo
