On Thu, 2019-05-30 at 08:27 -0700, Tamas K Lengyel wrote:
> On Thu, May 30, 2019 at 7:18 AM 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
On Thu, May 30, 2019 at 08:04:38PM +0100, Colin King wrote:
> 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")
Signed-off-by: Wei Liu
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c55b0fedbe2..e212c6a42ddf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17295,7 +17295,7 @@ F: Documentation/ABI/stable/sysfs-hypervisor-xen
F: Do
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 31 May 2019 08:31
> To: net...@vger.kernel.org
> Cc: Xen-devel ; Paul Durrant
> ; David Miller
> ; Wei Liu
> Subject: [PATCH net-next] Update my email address
>
> Signed-off-by: Wei Liu
Acked-by: Paul Durrant
>
Using clang and lld 8 requires installing the packages from the
official llvm apt repositories, so modify the Debian Docker files for
stretch and unstable to add the llvm repo and install clang and lld
from it.
Also add some jobs to test building Xen with clang 8 and lld.
Signed-off-by: Roger Pau
On 31/05/2019 01:17, Roger Pau Monne wrote:
> +deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
> +deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
> diff --git a/automation/build/debian/stretch.dockerfile
> b/automation/build/debian/stretch.dockerfile
> index daf8c
On Fri, May 31, 2019 at 01:21:15AM -0700, Andrew Cooper wrote:
> On 31/05/2019 01:17, Roger Pau Monne wrote:
> > +deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
> > +deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
> > diff --git a/automation/build/debian/stretch.d
1: guard top-of-stack reads
2: widen condition for logging top-of-stack
The issue patch 2 fixes (a curious lack of an intermediate call stack
entry) was observed in practice; patch 1 is a result of me just looking
at the code (and if I have missed some aspect of why this isn't a
problem in reality
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.
Sta
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 we'
>>> On 30.05.19 at 10:59, wrote:
>>
>>> +return false;
>>> +
>>> +rc = hvmemul_linear_to_phys(gla, &gpa, bytes, &reps, pfec, &ctxt);
>>
>> 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
>> resul
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: Ja
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 poi
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
___
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 w
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 really
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 B
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
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 emul-priv-op.c
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
https://lists.
>>> 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 *do
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 foll
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
+++ b/xen/arch/x
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 full
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
Signed-of
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
build-amd64-pre
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);
#end
>>> 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
>>> 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, i
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 filtered_fl
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 F
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 a/xen/co
> 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 m
>>> 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
>> +++ b/xen/include/
>>> 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
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 st
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
+++ b
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
> +++ b/xen/common
>>> 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
persona
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
---
x
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 ++
> xen/arch/x86/apic
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
--- a/xen/com
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 ru
>>> 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.
> --- a/xen
>>> 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 bloc
>>> 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. */
>> -boo
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 o
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: D
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 remov
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 b/x
> 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 depending
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
test-amd64-i386-exam
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 1
>>> 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
> +++ b/xen/c
>>> 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 selec
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 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
> >
> -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
> Beulic
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
drivers/xen/pvcalls-fro
> -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: Re
>>> 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 device
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
> > > schedulin
> -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 t
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
build-i386-prev
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
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 Mo
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 map
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 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 pe
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 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.
>> + * An
On 31/05/2019 08:59, Jan Beulich wrote:
>
>>> +#ifdef CONFIG_HAS_PCI
>>> +INIT_LIST_HEAD(&dom_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 suc
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
__
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
test-amd64-i386-li
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 advanta
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 interr
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 emul-priv-op.c:r
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 int
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: W
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 spinlock and not a spinlock_irq.
> Andre,
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
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 rep
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 sp
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 drop
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, I
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 Coo
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 instructio
> 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 (*flush_t
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 com
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
test-amd64-amd64-xl-qemuu-dmrest
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 1
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")
> S
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 21d9dc21f81828538af02
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 functio
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 change
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 Be
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 yo
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 to
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
"static_partit
1 - 100 of 111 matches
Mail list logo
