branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: ovmf https://githu
flight 96378 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-buildfail in 96355 REGR. vs. 87893
build-amd64-libvi
Hi,
This is fifth approach for replacing struct dma_attrs with unsigned
long.
The main patch (1/44) doing the change is split into many subpatches
for easier review (2-42). They should be squashed together when
applying.
Rebased on v4.7-rc5.
For easier testing the patchset is available here:
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/common/dmabounce.c | 4 +-
arch/arm/include/asm/dma-mapping.h | 13 +++--
arch/arm/include/asm/xen/page-coherent.h | 16 +++
ar
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
[for xen]
Acked-by: David Vrabel
---
drivers/xen/swiotlb-xen.c | 14 +++---
include/xen/swiotlb-xen.h | 12 ++--
2 files changed, 13 insertions(+),
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
---
arch/x86/include/asm/dma-mapping.h | 5 ++---
arch/x86/include/asm/swiotlb.h | 4 ++--
arch/x86/include/asm/xen/page-coherent.h | 9 -
After switching DMA attributes to unsigned long it is easier to just
compare the bits.
Signed-off-by: Krzysztof Kozlowski
[for avr32]
Acked-by: Hans-Christian Noren Egtvedt
[for arc]
Acked-by: Vineet Gupta
[for arm64 and dma-iommu]
Acked-by: Robin Murphy
---
Documentation/DMA-API.txt
>>> On 29.06.16 at 19:26, wrote:
> On Tue, Jun 28, 2016 at 1:37 AM, Jan Beulich wrote:
> On 27.06.16 at 20:08, wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3376,7 +3376,29 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>> HVMT
>>> On 29.06.16 at 18:27, wrote:
> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> To explain better what I'm trying to suggest here please take a look at
>> the attached patch. If we can guarantee long term that ACPI id always
>> equals to Xen's idea of vCPU id this is probably the easiest way.
>>
Hi Dirk,
On 29/06/16 16:49, Dirk Behme wrote:
On 22.06.2016 17:26, Julien Grall wrote:
On 21/06/16 11:16, Dirk Behme wrote:
Would it be possible to use the flags CLK_IGNORE_UNUSED instead? So the
clock will be ignored by clk_disable_unused_subtree.
Yes, using CLK_IGNORE_UNUSED is an option.
flight 96450 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96450/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't know that they
are used. The clock of the serial console handled by Xen is one
example for this. It migh
flight 96449 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96449/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On Thu, Jun 30, 2016 at 10:25:46AM +0200, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
>
> Signed-off-by: Krzysztof Kozlowski
> [for xen]
> Acked-by: David Vrabel
Acked-by: Konrad Rzeszutek Wilk
> ---
> drivers
On Sun, Jun 26, 2016 at 11:48:44PM +, Thierry Laurion wrote:
> Sorry for the precedent post that was written a bit too fast. Libreboot was
> flashed when I wrote it, which is the equivalent of a having vt-d
> deactivated (iommu=0). Thanks to a user that read this post and wrote to me
> personal
On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor. The p
flight 96470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96470/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane
On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
> Some clocks might be used by the Xen hypervisor and not by the Linux
> kernel. If these are not registered by the Linux kernel, they might be
> disabled by clk_disable_unused() as the kernel doesn't know that they
> are used. The clock o
On 30.06.2016 16:21, Mark Rutland wrote:
On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't
On Mon, Jun 27, 2016 at 01:13:43AM -0600, Jan Beulich wrote:
> >>> On 24.06.16 at 19:02, wrote:
> > On Fri, Jun 24, 2016 at 01:33:45AM -0600, Jan Beulich wrote:
> >> >>> On 22.06.16 at 19:15, wrote:
> >> > --- a/tools/firmware/hvmloader/hvmloader.c
> >> > +++ b/tools/firmware/hvmloader/hvmloader.
On Thu, Jun 30, 2016 at 10:01:18AM -0400, Daniel De Graaf wrote:
> On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
> > > This adds a Kconfig option and support for including the XSM policy from
> > > tools/flask/policy in the
Hi,
On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote:
> On 30.06.2016 16:21, Mark Rutland wrote:
> >On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
> >>+- clocks: one or more clocks to be registered.
> >>+ Xen hypervisor drivers might replace native drivers, resulting in
> >
Hi,
On 30/06/16 16:18, Mark Rutland wrote:
On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote:
On 30.06.2016 16:21, Mark Rutland wrote:
On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
+- clocks: one or more clocks to be registered.
+ Xen hypervisor drivers might replace n
flight 96476 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96476/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
these are the first 32 vCPUs from Xen's perspective and we should map them
accordingly with the newly introduced xen_vcpu_id mapping.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vr
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id
should be used. Use the newly introduced xen_vcpu_id mapping to convert
it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/xen/events/events_fif
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and
Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id
mapping to convert it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/x
HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while
Xen's idea is expected. In some cases these ideas diverge so we need to
do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use
xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps()
intact as they're
Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids dive
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
Update cpuid.h header from xen hypervisor tree to get
XEN_HVM_CPUID_VCPU_ID_PRESENT definition.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/xen/cpuid.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen
Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM
guests (while we had it for PV and ARM guests). This is usually fine as we
can use vcpu info in the sared_info page but when we try booting on a vCPU
with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this
CP
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/xen/evtchn.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/evtchn.c
When scripting, it is much more convenient to use:
[root@fusebot ~]# xl info xen_version
4.8-unstable
than to construct some sed/awk/other to parse:
[root@fusebot ~]# xl info
...
xen_version: 4.8-unstable
...
This works by wrapping all printf() calls in main_
flight 96447 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96447/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
This patch-series makes some adjustments and fixes to the X86 vm-events code.
Summary:
1. proper checks for vCPU pause @ vm_event_resume
2. minor optimization
3. relocate some code into added vm-event functions
4. turn monitor_write_data.do_write into enum
5. fix monitor_write_d
A VM_EVENT_FLAG_VCPU_PAUSED flag in a vm-event response should only be treated
as informative that the toolstack user wants the vm-event subsystem to unpause
the target vCPU, but not be relied upon to decide if the target vCPU is actually
paused.
That being said, this patch does the following:
*
Minor optimization @ vmx_update_guest_cr: checks if v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/vmx/vmx.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/h
For readability:
* Add function arch_monitor_write_data (in x86/monitor.c) and separate handling
of monitor_write_data there (previously done directly in hvm_do_resume).
* Add function write_ctrlreg_adjust_traps (in x86/monitor.c) and relocate
enabling/disabling of CPU_BASED_CR3_LOAD_EXITING for
After trapping a control-register write vm-event and -until- deciding if that
write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual write,
there cannot and should not be another trapped control-register write event.
That is, currently -only one- of the fields of monitor_write_da
The arch_vm_event structure is dynamically allocated and freed @
vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack user
disables domain monitoring (xc_monitor_disable), which in turn effectively
discards any information that was in arch_vm_event.write_data.
But this can yi
VM_EVENT_REASON_MOV_TO_MSR is X86-specific, surround w/ #ifdef accordingly.
Signed-off-by: Corneliu ZUZU
---
xen/common/vm_event.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 17d2716..89a25d1 100644
--- a/xen/common/vm_event.c
+++ b/x
Minor fixes:
- remove some empty lines
- remove some unused includes
- multi-line comment fixes
- 80-columns formatting fixes
Signed-off-by: Corneliu ZUZU
---
xen/arch/arm/domain.c | 1 -
xen/arch/arm/traps.c | 1 -
xen/arch/x86/hvm/hvm.c| 3 ---
xen/a
Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include strictly
where needed) and also change to asm/paging.h (include strictly what's needed).
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/monitor.c| 1 +
xen/include/asm-x86/hvm/monitor.h | 1 -
2 files changed, 1 i
flight 96459 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96459/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 96296
flight 96460 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96460/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 96378
pass in 96460
test-amd64-amd64-xl-
flight 96474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96474/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
>>> On 30.06.16 at 17:04, wrote:
> On Mon, Jun 27, 2016 at 01:13:43AM -0600, Jan Beulich wrote:
>> >>> On 24.06.16 at 19:02, wrote:
>> > On Fri, Jun 24, 2016 at 01:33:45AM -0600, Jan Beulich wrote:
>> >> >>> On 22.06.16 at 19:15, wrote:
>> >> > +for ( i = 0; i < info->nr_modules; i++ )
>> >>
On 06/30/16 21:45, Corneliu ZUZU wrote:
> The arch_vm_event structure is dynamically allocated and freed @
> vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack
> user
> disables domain monitoring (xc_monitor_disable), which in turn effectively
> discards any information tha
On 06/30/16 21:44, Corneliu ZUZU wrote:
> After trapping a control-register write vm-event and -until- deciding if that
> write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual
> write,
> there cannot and should not be another trapped control-register write event.
> That is, cur
On 7/1/2016 9:47 AM, Razvan Cojocaru wrote:
On 06/30/16 21:45, Corneliu ZUZU wrote:
The arch_vm_event structure is dynamically allocated and freed @
vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack user
disables domain monitoring (xc_monitor_disable), which in turn effe
On 06/30/16 21:47, Corneliu ZUZU wrote:
> Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include
> strictly
> where needed) and also change to asm/paging.h (include strictly what's
> needed).
>
> Signed-off-by: Corneliu ZUZU
> ---
> xen/arch/x86/hvm/monitor.c| 1 +
> x
54 matches
Mail list logo
