At 06:02 +0200 on 23 May (1527055365), Juergen Gross wrote:
> On 22/05/18 21:47, Marek Marczykowski-Górecki wrote:
> > Older gcc does not support #pragma GCC diagnostics, so use alternative
> > approach - change variable type to uint32_t (this code handle 32-bit
> > requests only anyway), which app
At 12:20 +0100 on 22 May (1526991646), Andrew Cooper wrote:
> Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are
> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
>
> SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs()
> and vmx_update_gues
We should index an L1 table with an L1 index.
Reported-by: Simon Gaiser
Signed-off-by: Jan Beulich
---
v2: Entirely different.
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -883,7 +883,7 @@ static void cleanup_cpu_root_pgt(unsigne
l2_pgentry_t *l2t = l3e_to_l2e(l3t[l3_ta
On 05/23/2018 02:46 PM, Juergen Gross wrote:
On 23/05/18 13:36, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t firs
On 24/05/18 16:07, Andrew Cooper wrote:
> This helps debug #DF's which occur in alternative patches
>
> Reported-by: George Dunlap
> Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xe
On 05/25/2018 01:59 AM, Sameer Goel wrote:
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
Hi Sameer,
General Comment, please use appropriate variable names for XXX_domain
structures in code which is xen specific.
I thought that we had discussed this before on one of the RFCs.
Yes and no one
flight 123086 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123086/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12
From: Zhongze Liu
Author: Zhongze Liu
Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
And deleted some trailing white spaces.
[1] https://lists.xen.org
From: Zhongze Liu
Author: Zhongze Liu
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs fr
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a master: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a
From: Zhongze Liu
Author: Zhongze Liu
Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
https://lists.xen.org/arch
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
Hi,
This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.
It was originally developed by Zhongze,
From: Zhongze Liu
Author: Zhongze Liu
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based com
Hi there
I'm trying to apply xsa263 patches, specifically for 4.10. However they
dont seem to on top of 4.10.1 release.
I see they do apply cleanly to current 4.10 staging branch. Are staging
trees for stable branches like 4.10 considered suitable/safe to rebase
to for packaging purposes? ie
This run is configured for baseline tests only.
flight 74741 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74741/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 77ca824c652443bdf3edaa0bb109fd8225a71cd3
baseline v
This run is configured for baseline tests only.
flight 74739 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 11 examine-serial/bo
flight 123079 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-xl-credit2 4 host-insta
flight 74740 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74740/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 74722
jobs:
build-amd64 pass
build-armh
On 05/24/2018 04:27 AM, Ian Jackson wrote:
Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""):
tl;dr:
I think there is a bug in libvirt's build system which, with
low probability, causes a build failure containing this message:
/usr/bin/ld: cannot find -lvirt
Comple
Hey Linus,
Please git pull the following branch in your tree:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-4.17
There is one single fix in there - that is under Xen the DMA32 heap
(in the hypervisor) would end up looking like swiss cheese. The reaso
flight 123101 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123101/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 77ca824c652443bdf3edaa0bb109fd8225a71cd3
baseline version:
ovmf 1e35fcc9ee8b6b991535d
On Thu, May 24, 2018 at 1:16 PM Steven Rostedt wrote:
> On Thu, 24 May 2018 13:40:24 +0200
> Petr Mladek wrote:
> > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > > When using -fPIE/PIC with function tracing, the compiler generates a
> > > call through the GOT (call *__fentry__@GOTPCREL)
flight 123075 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 122357
test-amd64-i386-f
On 05/24/2018 01:58 AM, Jan Beulich wrote:
On 24.05.18 at 02:46, wrote:
Pull common defines for SMMU drives in a local header.
Signed-off-by: Sameer Goel
---
xen/drivers/passthrough/arm/arm_smmu.h | 125 +
This being a local header - why the arm_ prefix?
I'll fix
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
Hi Sameer,
General Comment, please use appropriate variable names for XXX_domain
structures in code which is xen specific.
I thought that we had discussed this before on one of the RFCs. At this
point we are just using the format used for smmu-v2.
On 05/24/2018 01:57 AM, Jan Beulich wrote:
On 24.05.18 at 02:46, wrote:
--- /dev/null
+++ b/xen/include/xen/linux_compat.h
I continue to dislike the idea of having a header with these contents in this
location.
As explained previously this header can be used for the any driver that
we want
On 05/24/2018 01:53 AM, Jan Beulich wrote:
On 24.05.18 at 02:46, wrote:
Port WARN_ON_ONCE macro from Linux.
In such a case you should justify adjustments you've made:
I can add more details, but have mostly just changed variable names. The
macro is self explanatory.
Should I just change t
Can you please point out the specific instances? This patch is no
different than the last v1 patch. I have just added tasklets to it.
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
Hi Sameer,
General Comment, please use appropriate variable names for XXX_domain
structures in code which is xen s
On Thu, 24 May 2018 13:40:24 +0200
Petr Mladek wrote:
> On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > When using -fPIE/PIC with function tracing, the compiler generates a
> > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > takes 6 bytes instead of 5 on the usual rel
On 5/24/18 7:01 AM, Joe Perches wrote:
> On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
>> On 5/23/18 4:35 PM, Joe Perches wrote:
>>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
On 5/23/18 2:05 PM, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equiv
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Artem,
>
> Title: It would be good to specify the subsystem you modify.
>
> arm: vgic: ...
>
> On 24/05/18 16:24, Artem Mygaiev wrote:
> > vgic_vcpu_pending_irq() uses find_next_bit() library function with single
> > 'unsigned long' variable, while i
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 24/05/18 00:47, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Using current is fairly expensive, so save up into a variable.
> > >
> > > Signed-off-by: Julien Grall
> >
> > Good idea. I am curious to kn
On Thu, 24 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 20:21, wrote:
> > On Wed, 23 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 22:08, wrote:
> >> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >> >>> On 22.05.18 at 02:53, wrote:
> >> >> > + $(eval tmpfile := $(shell mktemp))
flight 123074 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 122969
test-amd64-amd64-xl-q
On 24/05/18 17:01, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote:
>> Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are
>> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
>>
>> SCE is handled by ad-hoc logic in context_switch
On 22/05/18 11:33, Jan Beulich wrote:
> Other than in the feature sets, where we indeed want to offer the
> feature even if not enumerated on hardware, we shouldn't dictate the
> feature being available if tool stack or host admin have decided not
> to expose it (for whatever [questionable?] reason
On Thu, May 24, 2018 at 4:04 AM Pavel Machek wrote:
> On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote:
> On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
>>> On 22.05.18 at 13:20, wrote:
> Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load
> and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and
> VM_ENTRY_MSR_LOAD_ADDR
> at the same page, and setting VM_EXIT_MSR_STORE_COUNT and
> VM_ENTRY_MSR_LOAD_COUNT to the same value.
Jan Beulich:
On 24.05.18 at 17:10, wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:14, wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact t
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
.gitignore | 1 +
tools/include/Makefile | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 7004349d5a..808f4f5497 100644
--- a/.gitignore
+++ b/.gitignore
@@ -198,6 +198,7 @@ tools/hot
Collect cpuid related things into a header file. Provide the necessary
macros to make it work.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
---
tools/libxc/xc_cpuid_x86.c | 6 +-
tools/libxc/xc_cpuid_x86.h | 16
2 files changed, 17 inserti
They are moved to a new header which is going to be consumed by both
the hypervisor and toolstack.
Create a new directory for this kind of headers in anticipation of
more will come.
No functional change.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Any suggestion on the direc
This is a step towards consolidating relevant data structures and
defines to one location.
It then requires defining cpuid_leaf in user space harness headers to
make them continue to compile.
No functional change.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/tests/x
---
tools/libxc/xc_cpuid_x86.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 89ded718bc..0af04a4e5a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -869,3 +869,20 @@ int xc_cpuid_set(
The hypervisor has some nice objects and definitions that toolstack can use,
too. Make that happen.
The anticipation is in the future MSR objects and definitions should be shared,
too.
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Andrew Cooper
Wei Liu (5):
x86: move definition of struct cpuid_leaf t
On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote:
> Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are
> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
>
> SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs()
> and vmx_update_g
On 24/05/18 16:08, Jan Beulich wrote:
On 22.05.18 at 13:20, wrote:
>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>> updates a host MSR load list entry with the current hardware value of
>> MSR_DEBUGCTL. This is wrong.
>>
>> On VMExit, hardware automatically res
>>> On 24.05.18 at 17:10, wrote:
> Jan Beulich:
> On 24.05.18 at 16:14, wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs sha
On 24/05/18 16:42, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote:
>> Up until this point, the MSR load/save lists have only ever accumulated
>> content. Introduce vmx_del_msr() as a companion to vmx_add_msr().
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> C
On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote:
> Up until this point, the MSR load/save lists have only ever accumulated
> content. Introduce vmx_del_msr() as a companion to vmx_add_msr().
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin T
On Tue, May 22, 2018 at 12:20:44PM +0100, Andrew Cooper wrote:
> Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load
> and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and VM_ENTRY_MSR_LOAD_ADDR
> at the same page, and setting VM_EXIT_MSR_STORE_COUNT and
> VM_ENTRY_MSR_LOA
Hi Artem,
Title: It would be good to specify the subsystem you modify.
arm: vgic: ...
On 24/05/18 16:24, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is designed to work with
memory regions and offsets. It wo
>>> On 24.05.18 at 17:10, wrote:
> Jan Beulich:
> On 24.05.18 at 16:14, wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs sha
On Thu 24-05-18 08:18:18, Matthew Wilcox wrote:
> On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > > If we had eight ZONEs, we could offer:
> >
> > No, please no more zones. What we have is quite a maint. burden on its
> > own. Ideally we should only have lowmem, highmem and speci
>>> On 22.05.18 at 13:20, wrote:
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL. This is wrong.
>
> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.
I'm pretty certain
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is designed to work with
memory regions and offsets. It would be more correct to use the
find_first_bit() function instead.
Signed-off-by: Artem Mygaiev
diff --git a/xen/arch/arm/gic-
Hi,
On 24.05.18 17:22, Julien Grall wrote:
On 24/05/18 15:07, Artem Mygaiev wrote:
Hi Julien
Hi Artem,
On 24.05.18 16:49, Julien Grall wrote:
Hi Artem,
Thank you for the report.
On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with
>>> On 24.05.18 at 16:18, wrote:
> Can you try with the "x86/traps: Dump the instruction stream even for
> double faults" patch I've just posted, and show the full #DF panic log
> please? (Its conceivable that there are multiple different issues here.)
Well, as long as we're on a guest kernel st
On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > If we had eight ZONEs, we could offer:
>
> No, please no more zones. What we have is quite a maint. burden on its
> own. Ideally we should only have lowmem, highmem and special/device
> zones for directly kernel accessible memory, t
Andrew Cooper:
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to rem
>>> On 22.05.18 at 13:20, wrote:
> @@ -537,25 +544,27 @@ enum vmx_msr_list_type {
> VMX_MSR_GUEST,
> };
>
> -int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type);
> +int vmx_add_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type);
>
> -static inline int vmx_add_host_load
>>> On 22.05.18 at 13:20, wrote:
> The main purpose of this change is to allow us to set a specific MSR value,
> without needing to know whether there is already a load/save list slot for
> it.
> Previously, callers wanting this property needed to call both vmx_add_*_msr()
> and vmx_write_*_msr()
Jan Beulich:
On 24.05.18 at 16:14, wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00, wrote:
Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it
> On May 24, 2018, at 3:53 PM, Andrew Cooper wrote:
>
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost al
>>> On 22.05.18 at 13:20, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key,
> const void *elt)
> struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type type)
> {
> stru
On 24/05/18 15:35, Simon Gaiser wrote:
> Andrew Cooper:
>> On 24/05/18 15:14, Simon Gaiser wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that mult
Andrew Cooper:
> On 24/05/18 15:14, Simon Gaiser wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00, wrote:
Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Ther
>>> On 24.05.18 at 16:24, wrote:
> On 24/05/18 15:22, Jan Beulich wrote:
> On 24.05.18 at 16:18, wrote:
>>> Can you try with the "x86/traps: Dump the instruction stream even for
>>> double faults" patch I've just posted, and show the full #DF panic log
>>> please? (Its conceivable that there
>>> On 24.05.18 at 16:14, wrote:
> Jan Beulich:
> On 24.05.18 at 16:00, wrote:
>>> Jan Beulich:
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to uncondi
On 24/05/18 15:22, Jan Beulich wrote:
On 24.05.18 at 16:18, wrote:
>> Can you try with the "x86/traps: Dump the instruction stream even for
>> double faults" patch I've just posted, and show the full #DF panic log
>> please? (Its conceivable that there are multiple different issues here.)
>
On 24/05/18 15:07, Artem Mygaiev wrote:
Hi Julien
Hi Artem,
On 24.05.18 16:49, Julien Grall wrote:
Hi Artem,
Thank you for the report.
On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is
>>> On 24.05.18 at 16:14, wrote:
> How many bug-fixes vs. XSAs are typically in a stable branch? I was under
> the impression that historically, the vast majority used to be XSAs with very
> few backports.
> However, this year this has really changed because Spectre and Meltdown
> related fixes
On 24/05/18 15:14, Simon Gaiser wrote:
> Jan Beulich:
> On 24.05.18 at 16:00, wrote:
>>> Jan Beulich:
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to un
>>> On 24.05.18 at 16:07, wrote:
> This helps debug #DF's which occur in alternative patches
>
> Reported-by: George Dunlap
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
On 24/05/2018, 10:00, "Jan Beulich" wrote:
>>> On 24.05.18 at 15:50, wrote:
>
> On 24/05/2018, 01:48, "Steven Haigh" wrote:
>
> On 2018-05-22 20:52, Steven Haigh wrote:
> > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
> >> >>> On 1
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringin
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it ma
Hi Julien
On 24.05.18 16:49, Julien Grall wrote:
Hi Artem,
Thank you for the report.
On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is designed to work with
memory regions. Nothing wrong is
This helps debug #DF's which occur in alternative patches
Reported-by: George Dunlap
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
---
xen/arch/x86/traps.c| 2 +-
xen/arch/x86/x86_64/traps.c | 1 +
xen/include/asm-x86/processor.h | 1 +
3 files changed, 3
>>> On 24.05.18 at 15:48, wrote:
> On 24/05/18 14:41, Jan Beulich wrote:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when b
>>> On 24.05.18 at 15:50, wrote:
>
> On 24/05/2018, 01:48, "Steven Haigh" wrote:
>
> On 2018-05-22 20:52, Steven Haigh wrote:
> > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
> >> >>> On 18.05.18 at 19:53, wrote:
> >> > Alternative workaround for this would be m
>>> On 24.05.18 at 14:39, wrote:
> On 24/05/18 13:14, Roger Pau Monné wrote:
>> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
>>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>>> updates a host MSR load list entry with the current hardware value of
>>>
On 24/05/2018, 01:48, "Steven Haigh" wrote:
On 2018-05-22 20:52, Steven Haigh wrote:
> On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
>> >>> On 18.05.18 at 19:53, wrote:
>> > Alternative workaround for this would be more frequent point releases
by
>> > default
Hi Artem,
Thank you for the report.
On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is designed to work with
memory regions. Nothing wrong is happening since 'offset' is set to 0
(other values
On 24/05/18 14:41, Jan Beulich wrote:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmap
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to unconditionally zap the mapping
when bringing down a CPU; it may only be unmapped when no other online
CPU uses that same pa
Jan Beulich:
On 23.05.18 at 00:21, wrote:
>> I have done some more testing in the meantime. The issue also affect
>> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
>> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
>> all .data/.rodata/.bss map
flight 123073 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-install fail REGR. vs. 122974
Tests which did not
vgic_vcpu_pending_irq() uses find_next_bit() library function with
single 'unsigned long' variable, while it is designed to work with
memory regions. Nothing wrong is happening since 'offset' is set to 0
(other values could lead to memory corruption), but it would be more
correct to use the fin
>>> On 23.05.18 at 00:21, wrote:
> I have done some more testing in the meantime. The issue also affect
> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
> all .data/.rodata/.bss mappings" as the comm
On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
> On 5/23/18 4:35 PM, Joe Perches wrote:
> > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
> > > On 5/23/18 2:05 PM, Joe Perches wrote:
> > > > Convert the S_ symbolic permissions to their octal equivalents as
> > > > using octal and not s
On 5/23/18 4:35 PM, Joe Perches wrote:
> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
>> On 5/23/18 2:05 PM, Joe Perches wrote:
>>> Convert the S_ symbolic permissions to their octal equivalents as
>>> using octal and not symbolic permissions is preferred by many as more
>>> readable.
>>>
>
On 24/05/18 13:14, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>> updates a host MSR load list entry with the current hardware value of
>> MSR_DEBUGCTL. This is wrong.
>>
>> On
On 22 May 2018 at 19:46, Stefano Stabellini wrote:
> The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39:
>
> Merge remote-tracking branch
> 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18
> 14:11:52 +0100)
>
> are available in the git reposit
On Wed 23-05-18 22:19:19, Matthew Wilcox wrote:
> On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> > So why is this any better than the current code. Sure I am not a great
> > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> > doesn't look too much better, yet w
On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote:
> From: Michal Hocko [mailto:mho...@kernel.org]
> Sent: Wednesday, May 23, 2018 2:37 AM
> >
> > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> > > From: Huaisheng Ye
> > >
> > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
>
On Thu, May 24, 2018 at 11:59:07AM +0100, Andrew Cooper wrote:
> On 24/05/18 11:53, Roger Pau Monné wrote:
> > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote:
> >> On 23/05/18 17:39, Roger Pau Monné wrote:
> >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
> In
On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL. This is wrong.
>
> On VMExit, hardware automatically resets MSR_DEBUGC
1 - 100 of 125 matches
Mail list logo
