Hi All,
On 8/25/2017 4:12 PM, Julien Grall wrote:
Hi all,
I would suggest to have the next community call on Wednesday 13th
September 2017 5pm BST. Does it sound good?
Do you have any specific topic you would like to discuss?
Will it be possible to have a small discussion on the PCI passthro
flight 113064 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113064/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113062 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113062/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113054 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113054/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Hello~~
I'm struggling to resolve a kernel panic problem during developing
scheduler code.
But I have not made any progress since I can not get any meaningful
information from the serial log.
When the panic occurred, always there is no call trace and only panic
notification like following:
(XEN)
(
flight 113059 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113059/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
This run is configured for baseline tests only.
flight 72065 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72065/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de
baseline v
flight 113051 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113051/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 113057 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113057/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113049 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113049/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
On Fri, 1 Sep 2017, Andrew Cooper wrote:
> asmlinkage is defined as nothing on all architectures, and not used
> consistently anywhere, even in common code. Remove it all.
>
> Signed-off-by: Andrew Cooper
I admit I liked the asmlinkage tag because it made it easier to browse
throw the code base
On Tue, 5 Sep 2017, Dario Faggioli wrote:
> So, I now think that what I did not understand, when looking at ARM
> code, was that context_switch() does indeed return, and hence we do at
> least another step inside the loop, and hit the ASSERT(), which I guess
> may trigger if what's in spite of the
flight 113055 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113055/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On 09/05/2017 03:32 PM, osstest service owner wrote:
> flight 113048 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/113048/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-win10-i
flight 113048 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 113031
test-amd64-i386-qem
flight 113050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de
baseline version:
ovmf 302860bfc467c72bdba91
On Fri, 25 Aug 2017, Julien Grall wrote:
> Hi all,
>
> I would suggest to have the next community call on Wednesday 13th September
> 2017 5pm BST. Does it sound good?
>
> Do you have any specific topic you would like to discuss?
Wednesday the 13th of September clashes with the Xilinx Embedded
So
On Tue, Sep 05, 2017 at 05:54:54PM +0100, Andrew Cooper wrote:
> This moves the L2 line to be consistent with the L3 line.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/
I've seen this problem with Xen 4.6.5 from the Xubuntu 16.04
distribution and from a quick look over the current vioapic code it
seems to be still present.
From the IOAPIC datasheet [1]: "To reference an IOAPIC register, a byte
memory write that the PIIX3 decodes for the IOAPIC loads the IOREGSEL
On Fri, 2017-06-09 at 18:41 +0200, Dario Faggioli wrote:
> Hey Praveen,
>
Hey, hello again!
> Here we are, sorry for the delay.
>
So, about this patch... I haven't seen a new version (or did I perhaps
miss it?).
I'm asking because I do have it half done myself, and it would not take
too much ti
On Thu, 2017-08-24 at 20:42 +0100, Anshul Makkar wrote:
> On 8/18/17 4:50 PM, Dario Faggioli wrote:
> >
> > @@ -1515,7 +1633,16 @@ static void reset_credit(const struct
> > scheduler *ops, int cpu, s_time_t now,
> > * that the credit it has spent so far get accounted.
> > *
flight 113053 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113053/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Wed, 2017-08-30 at 01:18 -0600, Jan Beulich wrote:
> > > > On 29.08.17 at 18:06, wrote:
> >
> > On 08/22/2017 02:04 PM, Jan Beulich wrote:
> > > > > > On 18.08.17 at 20:04, wrote:
> > > >
> > > > --- a/xen/arch/x86/cpu/mwait-idle.c
> > > > +++ b/xen/arch/x86/cpu/mwait-idle.c
> > > > @@ -741,
From: Manish Jaggi
This patch extends the gicv3_iomem_deny_access functionality by adding
support for ITS region as well. Add function gicv3_its_deny_access.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 22 ++
xen/arch/arm/gic-v3.c| 3 +++
From: Manish Jaggi
Added gicv3_its_acpi_init to update host_its_list from MADT table.
For ACPI, host_its structure stores dt_node as NULL.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 26 ++
xen/arch/arm/gic-v3.c| 2 ++
xen/include/as
From: Manish Jaggi
estimate_acpi_efi_size needs to be updated to provide correct size of
hardware domains MADT, which now adds ITS information as well.
Introducing gic_get_hwdom_madt_size.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/domain_build.c | 7 +--
xen/arch/arm/gic-v2.c |
From: Manish Jaggi
This patch is split into 5 patches. First two add support for updating
host_its_list from ACPI MADT table.
The rest patches provide support to update the hardware domain MADT table
with ITS information.
Changes since v2:
- %s/u32/unsigned long
- %s/u64/paddr_t
- cleanup gicv3_
From: Manish Jaggi
add_to_host_its_list will update the host_its_list. This common
function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_probe.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c | 32
1 file changed, 20 insertions(+), 12 dele
From: Manish Jaggi
Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 23 +++
xen/arch/arm/gic-v3.c| 1 +
xen/include/asm-arm/gic_v3_its.h | 8
3 files changed, 32 ins
Jan,
I'm really sorry, but would you mind sending this again (rebased if
you have it, without attachments)?
My tooling is completely failing to do anything sensible with this.
-George
On Wed, Jun 21, 2017 at 12:23 PM, Jan Beulich wrote:
> 01: support remaining AVX insns
> 02: re-order cases o
This moves the L2 line to be consistent with the L3 line.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 41ec78f
Reviewed-by: Petre Pircalabu
On Ma, 2017-09-05 at 09:41 +0100, Andrew Cooper wrote:
> Grp7 is abnormally complicated to decode, even by x86's standards,
> with
> {s,l}msw being the problematic cases.
>
> Previously, any value which fell through the first switch statement
> (looking
> for instruct
flight 113047 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 7 xen-boot fail REGR. vs. 113024
Regressions which
Paul Durrant writes:
>> Paul Durrant writes:
>>
>> >
>> > I wonder whether the easiest thing to do would be to modify qemu trad
>> > to do explicit ioreq server creation? It's really not that much
>> > code-change... 20-30 lines or so.
>>
>> I was thinking about this too, I'll try. It will hop
On Tue, Sep 5, 2017 at 2:47 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:18PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Add libxl__device_add to simple write XenStore device conifg
>> and libxl__device_add_async to update domain configuration
>> and write XenStore dev
When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.
Signed-off-by: Venu Busireddy
---
tools/xl/xl_vmcontrol.c | 9 +
1 file changed, 9 insertions(+)
diff --git
This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.
The original xen-pciback patch corresponding to t
Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.
Signed-off-by: Venu Busireddy
---
tools/libxl/libxl.
On Mon, Sep 4, 2017 at 6:40 AM, Daniel Kiper wrote:
> On Wed, Aug 30, 2017 at 10:16:23AM -0600, Tamas K Lengyel wrote:
>> On Tue, Aug 29, 2017 at 2:01 PM, Daniel Kiper
>> wrote:
>> > Hey Tamas,
>> >
>> > Sorry for late reply. I was on vacation.
>> >
>> > On Tue, Aug 22, 2017 at 09:01:06PM -0600,
On Ma, 2017-09-05 at 09:46 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 05.09.17 at 17:23, wrote:
> > On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > @@ -5177,7 +5177,7 @@ x86_emulate(
> > > > > >
On Wed, Aug 30, 2017 at 3:04 AM, Alexandru Isaila
wrote:
> The patch splits the vm_event into three structures:vm_event_share,
> vm_event_paging, vm_event_monitor. The allocation for the
> structure is moved to vm_event_enable so that it can be
> allocated/init when needed and freed in vm_event_di
On 05/09/17 14:22, Jan Beulich wrote:
> For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
> need to clone the respective hack used for CPUID_FAULTING. Introduce an
> inverse of setup_clear_cpu_cap() instead, but let clearing of features
> overrule forced setting of them.
>
> XE
> diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
> index 7567be66bd..66c7fe14fe 100644
> --- a/xen/include/asm-arm/monitor.h
> +++ b/xen/include/asm-arm/monitor.h
> @@ -57,12 +57,15 @@ static inline uint32_t
> arch_monitor_get_capabilities(struct domain *d)
> {
>
>>> On 05.09.17 at 17:32, wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] DEPS handling: Remove absolute paths
> from references to cwd"):
>> On 04.09.17 at 18:46, wrote:
>> > +%.d2: %.d
>>
>> Wouldn't it be better to use .%.d2 and .%.d here?
>
> Perhaps. That makes the assumption that nothing
On Mon, 2017-09-04 at 09:46 +0100, George Dunlap wrote:
> On 09/02/2017 04:39 PM, Julien Grall wrote:
> >
> > If I am not mistaken the hypervisor stack is per-vCPU. So when you
> > move the
> > vCPU to another pCPU, the stack will be moved.
> > This means the smp_processor_id() will return a diffe
>>> On 05.09.17 at 17:23, wrote:
> On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote:
>> > >
>> > > >
>> > > > @@ -5177,7 +5177,7 @@ x86_emulate(
>> > > > goto done;
>> > > > break;
>> > > > default:
>> > > > -goto cannot_emulate;
>> > > > +
On 09/05/2017 11:14 AM, Jan Beulich wrote:
On 05.09.17 at 16:54, wrote:
>> On 09/05/2017 10:42 AM, Boris Ostrovsky wrote:
> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages(
> * guest can control its own visibility of/through the cache.
> */
Jan Beulich writes ("Re: [PATCH 4/4] DEPS handling: Remove absolute paths from
references to cwd"):
> On 04.09.17 at 18:46, wrote:
> > +%.d2: %.d
>
> Wouldn't it be better to use .%.d2 and .%.d here?
Perhaps. That makes the assumption that nothing anywhere adds
anything to DEPS which does not
On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote:
> > >
> > > >
> > > > @@ -5177,7 +5177,7 @@ x86_emulate(
> > > > goto done;
> > > > break;
> > > > default:
> > > > -goto cannot_emulate;
> > > > +goto unimplemented_insn;
> > > While
>>> On 05.09.17 at 16:54, wrote:
> On 09/05/2017 10:42 AM, Boris Ostrovsky wrote:
@@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages(
* guest can control its own visibility of/through the cache.
*/
flush_page_to_ram(page_to_mfn(&pg[i]),
>>> On 14.08.17 at 16:28, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -594,15 +594,18 @@ static int iommu_remove_device(struct pci_dev *pdev);
>
> int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot,
> unsi
flight 113052 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113052/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
>>> On 14.08.17 at 16:28, wrote:
> So that it can be called from outside in order to get the size of regular PCI
> BARs. This will be required in order to map the BARs from PCI devices into PVH
> Dom0 p2m.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
__
>>> On 14.08.17 at 16:28, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1465,6 +1465,46 @@ int prepare_ring_for_helper(
> return 0;
> }
>
> +#if defined(CONFIG_HAS_PCI)
#ifdef please.
> +int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn, unsigned long
> nr_pa
>>> On 14.08.17 at 16:28, wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -559,6 +559,15 @@ ret_t do_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> ret = pci_mmcfg_reserved(info.address, info.segment,
> info.start
On 09/05/2017 10:42 AM, Boris Ostrovsky wrote:
>>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages(
>>> * guest can control its own visibility of/through the cache.
>>> */
>>> flush_page_to_ram(page_to_mfn(&pg[i]), !(memflags &
>>> MEMF_no_icache_flush)
>>> On 05.09.17 at 16:42, wrote:
>>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages(
>>> * guest can control its own visibility of/through the cache.
>>> */
>>> flush_page_to_ram(page_to_mfn(&pg[i]), !(memflags &
> MEMF_no_icache_flush));
>>> -
>>> -
>>> On 04.09.17 at 18:46, wrote:
> In some directories we use gcc on source files elsewhere, to generate
> a .o here in the current directory. Eg in tools/libxl/,
>gcc -I -o build.o /path/to/libacpi/build.c
> We pass -MMD and -MF options to generate a .d file right here.
>
> In the general c
On 05/09/17 16:31, Waiman Long wrote:
> On 09/05/2017 10:24 AM, Waiman Long wrote:
>> On 09/05/2017 10:18 AM, Juergen Gross wrote:
>>> On 05/09/17 16:10, Waiman Long wrote:
On 09/05/2017 09:24 AM, Juergen Gross wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages(
>> * guest can control its own visibility of/through the cache.
>> */
>> flush_page_to_ram(page_to_mfn(&pg[i]), !(memflags &
>> MEMF_no_icache_flush));
>> -
>> -if ( !(memflags & MEMF_no_scrub
This run is configured for baseline tests only.
flight 72063 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72063/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 302860bfc467c72bdba91af021a44e20789601dc
baseline v
On 09/05/2017 10:24 AM, Waiman Long wrote:
> On 09/05/2017 10:18 AM, Juergen Gross wrote:
>> On 05/09/17 16:10, Waiman Long wrote:
>>> On 09/05/2017 09:24 AM, Juergen Gross wrote:
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin
>>> On 05.09.17 at 16:11, wrote:
> I couldn't convince myself that just marking the head as PGC_state_inuse
> under the lock is safe, mostly because of how MCE handler may write the
> state while the allocator is walking (lock-free) the buddy.
Good point.
> @@ -974,13 +972,39 @@ static struct pa
On 09/05/2017 10:18 AM, Juergen Gross wrote:
> On 05/09/17 16:10, Waiman Long wrote:
>> On 09/05/2017 09:24 AM, Juergen Gross wrote:
>>> There are cases where a guest tries to switch spinlocks to bare metal
>>> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
>>> has the downsid
On 09/05/2017 10:08 AM, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 10:02:57AM -0400, Waiman Long wrote:
>> On 09/05/2017 09:24 AM, Juergen Gross wrote:
>>> +static inline bool native_virt_spin_lock(struct qspinlock *lock)
>>> +{
>>> + if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
>>> +
On 05/09/17 16:10, Waiman Long wrote:
> On 09/05/2017 09:24 AM, Juergen Gross wrote:
>> There are cases where a guest tries to switch spinlocks to bare metal
>> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
>> has the downside of falling back to unfair test and set scheme for
On 09/05/2017 09:24 AM, Juergen Gross wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
> has the downside of falling back to unfair test and set scheme for
> qspinlocks due to virt_spin_lock() detec
Instead, preserve PGC_need_scrub bit when setting PGC_state_inuse
state while still under the lock and clear those pages later.
Note that we still need to grub the lock when clearing PGC_need_scrub
bit since count_info might be updated during MCE handling in
mark_page_offline().
Signed-off-by: Bo
On Tue, Sep 05, 2017 at 10:02:57AM -0400, Waiman Long wrote:
> On 09/05/2017 09:24 AM, Juergen Gross wrote:
> > +static inline bool native_virt_spin_lock(struct qspinlock *lock)
> > +{
> > + if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
> > + return false;
> > +
>
> I think you can tak
On 05/09/17 14:56, Jan Beulich wrote:
> While these are latent issues only for now, correct them right away:
> - unnamed (in the SDM) EVEX bits need to be set/clear respectively
> - EVEX.V' (called RX in our code) needs to uniformly be 1 in non-64-bit
> modes,
> - EXEX.R' (called R in our code) i
On 09/05/2017 09:24 AM, Juergen Gross wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
> has the downside of falling back to unfair test and set scheme for
> qspinlocks due to virt_spin_lock() detec
On 05/09/17 15:55, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 03:24:43PM +0200, Juergen Gross wrote:
>> diff --git a/arch/x86/include/asm/qspinlock.h
>> b/arch/x86/include/asm/qspinlock.h
>> index 48a706f641f2..fbd98896385c 100644
>> --- a/arch/x86/include/asm/qspinlock.h
>> +++ b/arch/x86/in
While these are latent issues only for now, correct them right away:
- unnamed (in the SDM) EVEX bits need to be set/clear respectively
- EVEX.V' (called RX in our code) needs to uniformly be 1 in non-64-bit
modes,
- EXEX.R' (called R in our code) is uniformly being ignored in
non-64-bit modes.
On Tue, Sep 05, 2017 at 03:24:43PM +0200, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/qspinlock.h
> b/arch/x86/include/asm/qspinlock.h
> index 48a706f641f2..fbd98896385c 100644
> --- a/arch/x86/include/asm/qspinlock.h
> +++ b/arch/x86/include/asm/qspinlock.h
> @@ -17,6 +17,25 @@ stati
>>> On 05.09.17 at 15:36, wrote:
On 05.09.17 at 15:07, wrote:
>> On 10/07/17 08:25, Jan Beulich wrote:
>> What about the opcode independent cases? We should check that the two
>> MBZ bits (currently an anonymous bitfield) are zero, and the MBS bit
>> (currently evex.evex) is set.
>
> Yes,
On 10/07/17 08:24, Jan Beulich wrote:
> Going though the XED commits from the last couple of months made me
> notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non-
> 64-bit modes, leading to an insertion of stray 32-bits of zero in case
> the original instruction had the bit set.
>
>>> On 05.09.17 at 15:07, wrote:
> On 10/07/17 08:25, Jan Beulich wrote:
>> While these are latent issues only for now, correct them right away:
>> - EVEX.V' (called RX in our code) needs to uniformly be 1,
>> - EXEX.R' (called R in our code) is uniformly being ignored.
>>
>> Signed-off-by: Jan Be
>>> On 05.09.17 at 14:26, wrote:
> On 10/07/17 11:39, Jan Beulich wrote:
>> Real hardware wraps silently in most cases, so we should behave the
>> same. Also split real and VM86 mode handling, as the latter really
>> ought to have limit checks applied.
>>
>> Signed-off-by: Jan Beulich
>
> The ch
With the boot parameter "xen_nopvspin" specified a Xen guest should not
make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this set the
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
has the downside of falling back to unfair test and set scheme for
qspinlocks due to virt_spin_lock() detecting the virtualized
environment.
Make virt_spin_loc
Add a _paravirt_false() default function returning always false which
can be used for cases where a boolean pvops replacement should just
say "no".
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 2 ++
arch/x86/kernel/paravirt.c| 7 +++
arch/x86/kernel/pa
With virt_spin_lock() being a pvops function the bare metal case can be
optimized by patching the call away completely. In case a kernel running
as a guest it can decide whether to use paravitualized spinlocks, the
current fallback to the unfair test-and-set scheme, or to mimic the
bare metal behav
Instead of special casing pv_lock_ops.vcpu_is_preempted when patching
use _paravirt_false() on bare metal.
Signed-off-by: Juergen Gross
---
arch/x86/kernel/paravirt-spinlocks.c | 14 +-
arch/x86/kernel/paravirt_patch_32.c | 10 --
arch/x86/kernel/paravirt_patch_64.c | 10 --
On Tue, Sep 05, 2017 at 11:03:38AM +0200, Olaf Hering wrote:
> The returned value represents now units of bytes instead of longs.
>
> Fixes commit 11d0044a16 ("tools/libxc: Modify bitmap operations to take void
> pointers")
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse of setup_clear_cpu_cap() instead, but let clearing of features
overrule forced setting of them.
XEN_SMAP being wrong post-boot is a problem specifi
On Sat, Sep 02, 2017 at 01:56:35AM +0800, Zhongze Liu wrote:
> 2017-09-02 0:03 GMT+08:00 Wei Liu :
> > On Sun, Aug 27, 2017 at 04:36:12PM +0800, Zhongze Liu wrote:
> >> Add the parsing utils for the newly introduced libxl_static_sshm struct
> >> to the libxl/libxlu_* family. And add realated parsin
On 10/07/17 08:25, Jan Beulich wrote:
> While these are latent issues only for now, correct them right away:
> - EVEX.V' (called RX in our code) needs to uniformly be 1,
> - EXEX.R' (called R in our code) is uniformly being ignored.
>
> Signed-off-by: Jan Beulich
Those changes do match table 2-40
On Tue, Jul 18, 2017 at 05:25:30PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Due to changes in device framework setdefault function
> should have same format. Otherwise calling devicetype
> set_default causes segfault.
>
> Signed-off-by: Oleksandr Grytsov
Shouldn't this pat
On Tue, Jul 18, 2017 at 05:25:29PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Jul 18, 2017 at 05:25:28PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
> > > +rc = snprintf(connector_path, 128, "%s/%d", path,
> > > info->num_connectors);
>
> Why not use GCSPRINTF ? These statically sized buffers etc. are an
> invi
On Tue, Jul 18, 2017 at 05:25:27PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
> diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> index dd07a6c..16a6c8c 100644
> --- a/tools/libxl/libxl_nic.c
> +++ b/tools/libxl/libxl_nic.c
> @@
On Tue, Jul 18, 2017 at 05:25:26PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
[...]
> /*
> * Insert a CD-ROM device. A device corresponding to disk must already
> diff --git a/tools/libxl/libxl_checkpoint_device.c
> b/tools/libxl/libxl_checkpoint_device.c
> index 01e74b5..7bd
Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
> > +rc = snprintf(connector_path, 128, "%s/%d", path,
> > info->num_connectors);
Why not use GCSPRINTF ? These statically sized buffers etc. are an
invitation to bugs.
Ian.
___
Xe
On Tue, Jul 18, 2017 at 05:25:25PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Jul 18, 2017 at 05:25:24PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Jul 18, 2017 at 05:25:23PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
This needs rebasing.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Jul 18, 2017 at 05:25:20PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Signed-off-by: Oleksandr Grytsov
> ---
> tools/libxl/Makefile | 2 +-
> tools/libxl/libxl.h | 24 +++
> tools/libxl/libxl_create.c | 1 +
> tools/libx
On 10/07/17 08:24, Jan Beulich wrote:
> Recent changes to the SDM (and XED) have made clear that older hardware
> raising #UD when the bit is set was really an erratum. Generalize the
> so far AMD-only override.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
flight 113044 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113044/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-stop fail REGR.
vs. 113036
Regressi
1 - 100 of 160 matches
Mail list logo
