flight 105593 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
Hi,
I am seeing below panic with NUMA during DT mappings in alloc_heap_pages()
BUG_ON(pg[i].count_info != PGC_state_free);
However, this issue is not there with 4.7 version. The same NUMA board
boots fine.
With 4.8 or staging I see below panic.
I have add print in alloc_heap_pages to print pag
> On 1 Feb 2017, at 14:49, Juergen Gross wrote:
>
> On 27/01/17 12:47, Juergen Gross wrote:
>> XS_RESTRICT and the xenstore library function xs_restrict() have never
>> been usable in all configurations and there are no known users.
>>
>> This functionality was thought to limit access rights of
Specifying an empty cdrom device will result in a Xenstore entry
params = aio:(null)
as the physical device path isn't existing. This lets a domain booted
via OVMF hang as OVMF is checking for "aio:" only in order to detect
the empty cdrom case.
Use an empty string for the physical device path i
flight 105589 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw3 host-install(3)broken REGR. vs. 105576
test-amd64-i386-qe
>>> On 07.02.17 at 03:12, wrote:
> On Mon, Feb 6, 2017 at 7:43 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> Please find the full log in the attachment.
>>
>> Sadly that one is only a partial log again. I'd really need to see the
>> boot messages too, in particular to (hopefully)
flight 105597 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105597/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
>>> On 07.02.17 at 00:32, wrote:
> Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
> added a assertion that intack.vector is the highest priority vector. But
> according to the osstest, the assertion failed sometimes. More discussion can
> be found in the thread
> (http
>>> On 07.02.17 at 07:48, wrote:
> Some comment from QEMU/KVM code, in /arch/x86/kvm/lapic.c,
>
> int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
> {
> /* This may race with setting of irr in __apic_accept_irq() and
>* value returned may be wrong, but kvm_vcpu_kick() in __apic
On Tue, Feb 07, 2017 at 02:51:54AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 00:32, wrote:
> > Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
> > added a assertion that intack.vector is the highest priority vector. But
> > according to the osstest, the assertion f
s applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Boris-Ostrovsky/x86-boot-32-Convert-the-32-bit-pgtable-setup-code-from-assembly-to-C/20170207-014642
>> base: https://git.ker
On 07/02/2017 08:18, Vijay Kilari wrote:
Hi,
Hello,
I am seeing below panic with NUMA during DT mappings in alloc_heap_pages()
BUG_ON(pg[i].count_info != PGC_state_free);
However, this issue is not there with 4.7 version. The same NUMA board
boots fine.
I am a bit confused by what you ar
This run is configured for baseline tests only.
flight 68528 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68528/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-chec
On 06/02/17 18:00, Boris Ostrovsky wrote:
> Since we are not using PIC and (at least currently) don't have IOAPIC
> we want to make sure that acpi_irq_model doesn't stay set to
> ACPI_IRQ_MODEL_PIC (which is the default value). If we allowed it to
> stay then acpi_os_install_interrupt_handler() wou
>>> On 06.02.17 at 17:55, wrote:
> * Latch current once at the start.
> * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally, this
>is how hardware behaves, and avoids an unnecessary pagewalk.
Hmm, so you say #GP is being raised for all possible reasons, but
#PF can't res
On 06/02/17 08:39, Jan Beulich wrote:
> As such clearing of flags may have an impact on the selected rendezvous
> function, defer the establishing of a rendezvous function other than
> the initial default one (std) until after all APs have been brought up.
>
> But don't allow such feature flags to
On 07/02/17 10:19, Jan Beulich wrote:
> >>> On 06.02.17 at 17:55, wrote:
>> * Latch current once at the start.
>> * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally,
>> this
>>is how hardware behaves, and avoids an unnecessary pagewalk.
> Hmm, so you say #GP is being ra
>>> On 07.02.17 at 11:27, wrote:
> On 06/02/17 08:39, Jan Beulich wrote:
>> As such clearing of flags may have an impact on the selected rendezvous
>> function, defer the establishing of a rendezvous function other than
>> the initial default one (std) until after all APs have been brought up.
>>
>>> On 07.02.17 at 11:39, wrote:
> On 07/02/17 10:19, Jan Beulich wrote:
>> >>> On 06.02.17 at 17:55, wrote:
>>> * Latch current once at the start.
>>> * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally,
>>> this
>>>is how hardware behaves, and avoids an unnecessary pa
The "reg" variable in fuzz_read_msr stores the real MSR index, not an
index within the fuzzer.
The rest of that function already handles things correctly. We just need
to remove the bogus check.
Signed-off-by: Wei Liu
---
tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c | 3 ---
1
On 07/02/17 11:02, Wei Liu wrote:
> The "reg" variable in fuzz_read_msr stores the real MSR index, not an
> index within the fuzzer.
>
> The rest of that function already handles things correctly. We just need
> to remove the bogus check.
"Spotted by Coverity."
> Signed-off-by: Wei Liu
Reviewed
flight 105599 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105599/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c609a144b6636577dd60fbaa5fc64efeecd7baf
baseline version:
ovmf 8a399fab0af391945f0ea
>>> On 06.02.17 at 15:57, wrote:
> Any fail during the original __vmwrite() leads to BUG() which can be
> easily exploited from a guest in the nested vmx mode.
>
> The new function returns error code depending on the outcome:
>
> VMsucceed: 0
> VMfailValid: VM Instruction Error
On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall wrote:
> On 07/02/2017 08:18, Vijay Kilari wrote:
>>
>> Hi,
>
>
> Hello,
>
>>I am seeing below panic with NUMA during DT mappings in
>> alloc_heap_pages()
>> BUG_ON(pg[i].count_info != PGC_state_free);
>> However, this issue is not there with 4.7 ve
On Tue, Feb 07, 2017 at 09:06:55AM +, David Scott wrote:
>
> > On 1 Feb 2017, at 14:49, Juergen Gross wrote:
> >
> > On 27/01/17 12:47, Juergen Gross wrote:
> >> XS_RESTRICT and the xenstore library function xs_restrict() have never
> >> been usable in all configurations and there are no kno
On 07/02/2017 11:10, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall wrote:
On 07/02/2017 08:18, Vijay Kilari wrote:
I am seeing below panic with NUMA during DT mappings in
alloc_heap_pages()
BUG_ON(pg[i].count_info != PGC_state_free);
However, this issue is not there with
On 02/02/17 16:20, Jan Beulich wrote:
On 02.02.17 at 16:41, wrote:
>> On 02/02/17 15:25, Jan Beulich wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -329,13 +329,16 @@ unsigned long __init alloc_boot_pages(
>>> unsigned long nr_pfns, unsigned long pfn_al
On 02/07/2017 10:47 AM, Jan Beulich wrote:
On 07.02.17 at 11:27, wrote:
>> On 06/02/17 08:39, Jan Beulich wrote:
>>> As such clearing of flags may have an impact on the selected rendezvous
>>> function, defer the establishing of a rendezvous function other than
>>> the initial default one (st
Hi Andre,
On 06/02/2017 19:16, Julien Grall wrote:
On 30/01/17 18:31, Andre Przywara wrote:
+/* Wait for an ITS to become quiescient (all ITS operations
completed). */
s/quiescient/quiescent/
+static int gicv3_its_wait_quiescient(struct host_its *hw_its)
s/quiescient/quiescent/
+{
+
Creating a domain with an invalid controller specification for a pvusb
device will currently segfault.
Avoid this by bailing out early in case of a mandatory xenstore path
not existing.
Signed-of-by: Juergen Gross
---
This patch is a backport candidate for 4.8
---
tools/libxl/libxl_usb.c | 13 +
On 07/02/17 11:09, Jan Beulich wrote:
>
>> @@ -423,6 +429,29 @@ static inline bool_t __vmread_safe(unsigned long field,
>> unsigned long *value)
>> return okay;
>> }
>>
>> +static always_inline unsigned long vmwrite_safe(unsigned long field,
>> +
Hi Andre,
Continuing the review where I left it yesterday.
On 30/01/2017 18:31, Andre Przywara wrote:
[...]
+/* Wait for an ITS to become quiescient (all ITS operations completed). */
+static int gicv3_its_wait_quiescient(struct host_its *hw_its)
+{
+uint32_t reg;
+s_time_t deadline =
Hello Al,
Thanks for your comments, please see below.
On Mon, Feb 06, 2017 at 04:06:45PM -0700, Al Stone wrote:
> On 01/24/2017 07:20 AM, Boris Ostrovsky wrote:
> >
> >> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT
> >> there's
> >> no way to reserve anything in there
On Tue, Feb 7, 2017 at 4:58 PM, Julien Grall wrote:
> On 07/02/2017 11:10, Vijay Kilari wrote:
>>
>> On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall wrote:
>>>
>>> On 07/02/2017 08:18, Vijay Kilari wrote:
I am seeing below panic with NUMA during DT mappings in
alloc_heap_pages()
>>
On 07/02/2017 12:41, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 4:58 PM, Julien Grall wrote:
On 07/02/2017 11:10, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall wrote:
On 07/02/2017 08:18, Vijay Kilari wrote:
I am seeing below panic with NUMA during DT mappings in
On 07/02/2017 12:47, Julien Grall wrote:
On 07/02/2017 12:41, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 4:58 PM, Julien Grall
wrote:
On 07/02/2017 11:10, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall
wrote:
On 07/02/2017 08:18, Vijay Kilari wrote:
I am seeing
On Mon, Feb 06, 2017 at 06:25:57PM +0800, G.R. wrote:
> On Mon, Feb 6, 2017 at 5:33 PM, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Sun, Feb 05, 2017 at 04:05:32PM +0800, G.R. wrote:
> >> Hi all,
> >> dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2.
> >>
> >> The system boot
>>> On 07.02.17 at 12:59, wrote:
> On 07/02/17 11:09, Jan Beulich wrote:
>>
>>> @@ -423,6 +429,29 @@ static inline bool_t __vmread_safe(unsigned long
>>> field,
> unsigned long *value)
>>> return okay;
>>> }
>>>
>>> +static always_inline unsigned long vmwrite_safe(unsigned long field,
>>
flight 105604 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105604/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a316d7ac91d302085b5c35d76db703f2208ec026
baseline version:
ovmf 7c609a144b6636577dd60
>>> On 07.02.17 at 12:38, wrote:
> On 02/02/17 16:20, Jan Beulich wrote:
> On 02.02.17 at 16:41, wrote:
>>> On 02/02/17 15:25, Jan Beulich wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -329,13 +329,16 @@ unsigned long __init alloc_boot_pages(
u
On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall wrote:
>
>
> On 07/02/2017 12:47, Julien Grall wrote:
>>
>>
>>
>> On 07/02/2017 12:41, Vijay Kilari wrote:
>>>
>>> On Tue, Feb 7, 2017 at 4:58 PM, Julien Grall
>>> wrote:
On 07/02/2017 11:10, Vijay Kilari wrote:
>
>
> On Tue, Feb
On 07/02/2017 13:25, Vijay Kilari wrote:
On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall wrote:
One more thing, if Xen 4.7 was able to go up to booting Dom0 without any
patches on a NUMA board. I would recommend to try to bisect and see if you
can find an offending commit.
Yes, with plain 4
On Tue, Feb 07, 2017 at 03:04:32AM -0700, Jan Beulich wrote:
On 07.02.17 at 07:48, wrote:
>> Some comment from QEMU/KVM code, in /arch/x86/kvm/lapic.c,
>>
>> int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
>> {
>> /* This may race with setting of irr in __apic_accept_irq() and
>>
>>> On 07.02.17 at 07:32, wrote:
> On Tue, Feb 07, 2017 at 03:04:32AM -0700, Jan Beulich wrote:
> On 07.02.17 at 07:48, wrote:
>>> Some comment from QEMU/KVM code, in /arch/x86/kvm/lapic.c,
>>>
>>> int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
>>> {
>>> /* This may race with sett
On Tue, Feb 07, 2017 at 10:47:01AM +0800, Yi Sun wrote:
> Hi,
>
> Thanks for reviewing! I agree with your comments except below one. Could you
> please check my response?
>
> On 17-01-31 15:29:34, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 19, 2017 at 02:01:09PM +0800, Yi Sun wrote:
> > > +int
On Tue, Feb 07, 2017 at 10:51:27AM +0800, Yi Sun wrote:
> On 17-01-31 15:57:26, Konrad Rzeszutek Wilk wrote:
> > > static int assemble_val_array(uint64_t *val,
> > > @@ -550,7 +641,25 @@ static int assemble_val_array(uint64_t *val,
> > >const struct psr_socket_info
On Mon, Feb 06, 2017 at 03:53:58AM -0700, Jan Beulich wrote:
> Konrad, Roger,
>
> we've recently had a report of stuck I/O (with slightly over a hundred
> frontend instances in a single guest), which turned out to be a simple
> lack of configured grants on the system. This raises two questions:
>
Hi Andre,
On 30/01/2017 18:31, Andre Przywara wrote:
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respec
>>> On 07.02.17 at 14:59, wrote:
> On Mon, Feb 06, 2017 at 03:53:58AM -0700, Jan Beulich wrote:
>> Interestingly I've found
>> https://groups.google.com/forum/#!topic/linux.kernel/N6Q171xkIkM
>> when looking around - is there a reason this or something similar
>> never made it into the driver? W
flight 105594 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 14 guest-saverestore fail REGR. vs. 59254
test-amd64-amd64-xl
flight 105605 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105605/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Tue, Feb 07, 2017 at 06:46:16AM -0700, Jan Beulich wrote:
On 07.02.17 at 07:32, wrote:
>> On Tue, Feb 07, 2017 at 03:04:32AM -0700, Jan Beulich wrote:
>> On 07.02.17 at 07:48, wrote:
Some comment from QEMU/KVM code, in /arch/x86/kvm/lapic.c,
int kvm_lapic_find_highest_
flight 105602 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
This fixes a crash when running out of grant refs when creating many
queues across many netdevs.
* If creating queues fails (i.e. there are no grant refs available),
call xenbus_dev_fatal() to ensure that the xenbus device is set to the
closed state.
* If no queues are created, don't call xennet_d
On Tue, 2017-02-07 at 04:09 -0700, Jan Beulich wrote:
> > > > On 06.02.17 at 15:57, wrote:
> >
> > Any fail during the original __vmwrite() leads to BUG() which can be
> > easily exploited from a guest in the nested vmx mode.
> >
> > The new function returns error code depending on the outcome:
This run is configured for baseline tests only.
flight 68531 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68531/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c609a144b6636577dd60fbaa5fc64efeecd7baf
baseline v
That way we have one person who can: a) poke other maintainers
or pull them in with new drivers are introduced, b) we have
one maintainer who can shepherd the patches along instead of
depending on the REST maintainers which may be busy with
other responsibilities.
Acked-by: Stefano Stabellini
Ack
On 07/02/17 15:06, Sergey Dyasli wrote:
> On Tue, 2017-02-07 at 04:09 -0700, Jan Beulich wrote:
> On 06.02.17 at 15:57, wrote:
>>> Any fail during the original __vmwrite() leads to BUG() which can be
>>> easily exploited from a guest in the nested vmx mode.
>>>
>>> The new function returns err
On Tue, Feb 07, 2017 at 07:13:57AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 14:59, wrote:
> > On Mon, Feb 06, 2017 at 03:53:58AM -0700, Jan Beulich wrote:
> >> Interestingly I've found
> >> https://groups.google.com/forum/#!topic/linux.kernel/N6Q171xkIkM
> >> when looking around - is there
On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
On 05.02.17 at 06:51, wrote:
>> I finally get some spare time to collect the debug info.
>
> As I continue to be puzzled, best I could come up with is an
> extension to the debug patch. Please use the attached one
> in place of the earlier o
On Tue, 2017-02-07 at 06:52 +, Tian, Kevin wrote:
> > From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> > Sent: Monday, February 06, 2017 10:58 PM
> >
> > There is an issue with the original __vmread() in nested vmx mode:
> > emulation of a guest's VMREAD with invalid arguments leads to
On Tue, Feb 7, 2017 at 6:57 PM, Julien Grall wrote:
>
>
> On 07/02/2017 13:25, Vijay Kilari wrote:
>>
>> On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall wrote:
>>>
>>>
>>> One more thing, if Xen 4.7 was able to go up to booting Dom0 without any
>>> patches on a NUMA board. I would recommend to try t
>>> On 07.02.17 at 08:28, wrote:
> On Tue, Feb 07, 2017 at 06:46:16AM -0700, Jan Beulich wrote:
> On 07.02.17 at 07:32, wrote:
>>> On Tue, Feb 07, 2017 at 03:04:32AM -0700, Jan Beulich wrote:
>>> On 07.02.17 at 07:48, wrote:
> Some comment from QEMU/KVM code, in /arch/x86/kvm/lapic.c
>>> On 07.02.17 at 16:06, wrote:
> If I understood correctly, you are suggesting the following change:
Mostly.
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -424,8 +424,8 @@ static inline unsigned long vmread_safe(unsigned long
> field,
> return r
flight 105600 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105600/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-raw 3 host-install(3) broken in 105589 pass in 105600
test-amd64-i386-qemut-rhel6hvm-a
>>> On 07.02.17 at 16:24, wrote:
> Or maybe we should just disable persistent grants by default, by setting
> xen_blkif_max_pgrants = 0. This feature doesn't scale well, and interacts
> badly
> with other things (like indirect descriptors). The amount of code required to
> maintain this feature i
>>> On 07.02.17 at 16:28, wrote:
> v2: - Added Acks
> - changed description in MAINTAINERS
> - changed file directory in MAINTAINERS
Are you sure? I can't see a difference to v1, so my earlier comment
still holds.
Jan
___
Xen-devel mailing li
On 07/02/17 16:22, Jan Beulich wrote:
On 07.02.17 at 16:06, wrote:
>> If I understood correctly, you are suggesting the following change:
> Mostly.
>
>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>> @@ -424,8 +424,8 @@ static inline unsigned long vmread
On Tue, Feb 07, 2017 at 09:31:29AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 16:28, wrote:
> > v2: - Added Acks
> > - changed description in MAINTAINERS
> > - changed file directory in MAINTAINERS
>
> Are you sure? I can't see a difference to v1, so my earlier comment
> still holds.
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the
>>> On 07.02.17 at 17:38, wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -304,6 +304,11 @@ X: xen/arch/x86/acpi/lib.c
> F: xen/drivers/cpufreq/
> F: xen/include/acpi/cpufreq/
>
> +PUBLIC INTERFACES AND PV DRIVERS DESIGNS
> +M: Konrad Rzeszutek Wilk
> +S: Supported
> +F: xen/
>>> On 07.02.17 at 17:34, wrote:
> On 07/02/17 16:22, Jan Beulich wrote:
> On 07.02.17 at 16:06, wrote:
>>> If I understood correctly, you are suggesting the following change:
>> Mostly.
>>
>>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>>> @@ -424,8 +
Hello,
Setting, e.g. 16 VCPUs for a HVM guest, ends up blocking the guest
completely when subscribing to vm_events, apparently because of this
code in xen/common/vm_event.c:
315 /* Give this vCPU a black eye if necessary, on the way out.
316 * See the comments above wake_blocked() for mo
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the
flight 105609 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Tue, Feb 07, 2017 at 09:47:09AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 17:38, wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -304,6 +304,11 @@ X: xen/arch/x86/acpi/lib.c
> > F: xen/drivers/cpufreq/
> > F: xen/include/acpi/cpufreq/
> >
> > +PUBLIC INTERFACES AND PV DRI
>>> On 07.02.17 at 18:02, wrote:
> On Tue, Feb 07, 2017 at 09:47:09AM -0700, Jan Beulich wrote:
>> >>> On 07.02.17 at 17:38, wrote:
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -304,6 +304,11 @@ X:xen/arch/x86/acpi/lib.c
>> > F:xen/drivers/cpufreq/
>> > F:xen/includ
flight 105610 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
Hi,
Facing a issue where bootstorm of guests leads to host crash. I debugged
and found that that enabling PML introduces a race condition during
guest teardown stage while disabling PML on a vcpu and context switch
happening for another vcpu.
Crash happens only on Broadwell processors as
There's nothing wrong with allowing the domain to perform DMA transfers to
MMIO areas that it already can access from the CPU, and this allows us to
remove the hack in set_identity_p2m_entry for PVH Dom0.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
---
Cc:
Current __hvm_copy assumes that the destination memory belongs to the current
vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
functions are used with current being the idle vcpu. Add a new vcpu parameter
to hvm copy in order to solve that. Note that only hvm_copy_to_guest_
On Thu, Jan 26, 2017 at 09:46:46AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Reviewed-by: Stefano Stabellini
Reviewed-by: Konrad Rzeszutek Wilk
Thank you for documenting this!
___
Xen-devel mailing list
Xen-devel@lis
This run is configured for baseline tests only.
flight 68532 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68532/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a316d7ac91d302085b5c35d76db703f2208ec026
baseline v
On 02/06/2017 12:00 PM, Boris Ostrovsky wrote:
> PVHv2 support for unprivileged guests.
>
> Changes in v3:
> * See patches 4 and 5
>
Applied to for-linus-4.11
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Andrii Anisov
Some drivers need additional dma ops to be provided by xen swiotlb. Because
common operations implementation came from x86 world and does not suite ARM
needs we have to provide needed XEN SWIOTLB for ARM callbacks.
dma_mmap patch is a port of an antique and lost patch discuss
From: Stefano Stabellini
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 1 +
drivers/xen/swiotlb-xen.c | 19 +++
include/x
From: Andrii Anisov
Signed-off-by: Andrii Anisov
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 1 +
drivers/xen/swiotlb-xen.c | 28
include/xen/swiotlb-xen.h | 6 ++
3 files changed, 35 insertions(+)
diff --git a/arch/arm/xen/mm.c b/arch/
Hi Andre,
On 30/01/2017 18:31, Andre Przywara wrote:
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs
flight 68530 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68530/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start fail blocked in 68502
test-amd64-i38
On 01/24/2017 11:23 AM, Juergen Gross wrote:
> On 24/01/17 14:47, Boris Ostrovsky wrote:
>> On 01/23/2017 01:59 PM, Boris Ostrovsky wrote:
>>> On 01/23/2017 05:09 AM, Juergen Gross wrote:
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or use
On Tue, Feb 7, 2017 at 9:53 AM, Razvan Cojocaru
wrote:
> Hello,
>
> Setting, e.g. 16 VCPUs for a HVM guest, ends up blocking the guest
> completely when subscribing to vm_events, apparently because of this
> code in xen/common/vm_event.c:
>
> 315 /* Give this vCPU a black eye if necessary, on
Both patches are fine by me.
On Tue, 7 Feb 2017, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Some drivers need additional dma ops to be provided by xen swiotlb. Because
> common operations implementation came from x86 world and does not suite ARM
> needs we have to provide needed XEN SWIOTLB
Jan Beulich writes ("Re: [PATCH v2] MAINTAINERS: Add myself as the public API
"Czar""):
> On 07.02.17 at 18:02, wrote:
> > Changed it locally to be that.
>
> With that
> Acked-by: Jan Beulich
Likewise.
Ian.
___
Xen-devel mailing list
Xen-devel@lis
On 02/07/2017 08:15 PM, Tamas K Lengyel wrote:
>
>
> On Tue, Feb 7, 2017 at 9:53 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> Hello,
>
> Setting, e.g. 16 VCPUs for a HVM guest, ends up blocking the guest
> completely when subscribing to vm_events, apparently b
Juergen Gross writes ("[PATCH] libxl: don't segfault when creating domain with
invalid pvusb device"):
> Creating a domain with an invalid controller specification for a pvusb
> device will currently segfault.
>
> Avoid this by bailing out early in case of a mandatory xenstore path
> not existing
On 07/02/17 18:31, Razvan Cojocaru wrote:
> On 02/07/2017 08:15 PM, Tamas K Lengyel wrote:
>>
>> On Tue, Feb 7, 2017 at 9:53 AM, Razvan Cojocaru
>> mailto:rcojoc...@bitdefender.com>> wrote:
>>
>> Hello,
>>
>> Setting, e.g. 16 VCPUs for a HVM guest, ends up blocking the guest
>> complete
While adjusting these functions, use unsigned int rather than uint8_t for the
loop variable, and fix the whitespace style.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/arch/x86/mm/p2m.c | 36 +-
Until the IPI has completed, other processors might be running on this nested
p2m object. clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.
This is currently safe as other issues prevents a nes
On Thu, Jan 26, 2017 at 09:46:47AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
Usually you say a bit in the description of what it does and
what's its usage is.
Like:
"Multi-touch fields re-use the page that is used by the other features
which means that you can int
There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update. This reduces the generated assembly from a read,
local modify, write to a single add instruction.
Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modif
1 - 100 of 171 matches
Mail list logo
