flight 117022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117022/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 116992 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116992/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 107552
test-armhf-armhf-libvirt 14 sav
flight 117017 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117017/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
This run is configured for baseline tests only.
flight 72527 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 6 xen-build
flight 116961 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116961/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 116762
Tests which ar
flight 117015 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117015/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
On Sat, 28 Oct 2017, Simon Gaiser wrote:
> The passed-through device might be an express device. In this case the
> old code allocated a too small emulated config space in
> pci_config_alloc() since pci_config_size() returned the size for a
> non-express device. This leads to an out-of-bound write
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
> On Fri, 8 Dec 2017, Julien Grall wrote:
> > On 06/12/17 12:27, Julien Grall wrote:
> > > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > > On Thu, 23 Nov 2017, Julien Grall
On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 06/12/17 12:27, Julien Grall wrote:
> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > Hi Andrew,
> > > >
> > > > On 23/11/17 18:49, Andrew Coope
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 06/12/17 12:27, Julien Grall wrote:
> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > Hi Andrew,
> > > >
> > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > > > > On 23/11/17 18:32, Julien Grall
On Thu, 7 Dec 2017, Andre Przywara wrote:
> The functions to actually populate a list register were accessing
> the VGIC internal pending_irq struct, although they should be abstracting
> from that.
> Break the needed information down to remove the reference to pending_irq
> from gic-v[23].c.
>
>
On Thu, 7 Dec 2017, Andre Przywara wrote:
> Currently gic_dump_info() not only dumps the hardware state of the GIC,
> but also the VGIC internal virtual IRQ lists.
> Split the latter off and move it into gic-vgic.c to observe the abstraction.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefan
On Thu, 7 Dec 2017, Andre Przywara wrote:
> Currently gic.c holds code to handle hardware IRQs as well as code to
> bridge VGIC requests to the GIC virtualization hardware.
> Despite being named gic.c, this file reaches into the VGIC and uses data
> structures describing virtual IRQs.
> To improve
Hi,
On 12/07/2017 04:14 PM, Andre Przywara wrote:
The global variable "nr_irqs" is used for x86 and some common Xen code.
To make the latter work easily for ARM, it was #defined to NR_IRQS.
This not only violated the common habit of capitalizing macros, but
also caused issues if one wanted to us
On Thu, 7 Dec 2017, Andre Przywara wrote:
> In gic_restore_pending_irqs() we push our pending virtual IRQs into the
> list registers. This function is called once from a GIC context and once
> from a VGIC context. Refactor the calls so that we have only one callsite
> from the VGIC context. This wi
On 12/08/2017 12:56 PM, Bjorn Helgaas wrote:
> On Wed, Dec 06, 2017 at 01:51:18PM -0600, Bjorn Helgaas wrote:
>> On Wed, Nov 29, 2017 at 03:12:29PM +0100, Christian König wrote:
>>> This avoids problems with Xen which hides some memory resources from the
>>> OS and potentially also allows memory ho
On Thu, 7 Dec 2017, Andre Przywara wrote:
> gic_remove_irq_from_queues() was not only misnamed, it also has the wrong
> abstraction, as it should not live in gic.c.
> Move it into vgic.c and vgic.h, where it belongs to, and rename it on
> the way.
>
> Signed-off-by: Andre Przywara
> Reviewed-by:
On Fri, 8 Dec 2017, Julien Grall wrote:
> Hi,
>
> On 29/11/17 18:12, Stefano Stabellini wrote:
> > On Wed, 29 Nov 2017, Julien Grall wrote:
> > > Per the device-tree specific [1], when the property #address-cells
> > > and #size-cells are not present, the default value should be resp. 1
> > > and
On Fri, 8 Dec 2017, Julien Grall wrote:
> Hi,
>
> Ping?
>
> Cheers,
>
> On 29/11/17 17:46, Julien Grall wrote:
> > The value of the macro HCR_SYSREG is not surrounded by (). This means
> > the behavior may change depend on how it is used.
> >
> > Thanksfully recent GCC will issue a warning for
On Fri, 8 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 07/12/17 23:05, Stefano Stabellini wrote:
> > On Wed, 6 Dec 2017, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > When system registers are not enabled, all the access to them will trap
> >
On Fri, 8 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 07/12/17 23:01, Stefano Stabellini wrote:
> > On Wed, 6 Dec 2017, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 12/06/2017 01:22 AM, Stefano Stabellini wrote:
> > > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > > The only di
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
> This patch exports pcie_has_flr() and it is being used by Xen pciback
> driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
> attribute.
>
> Signed-off-by: Govinda Tatti
> ---
> v3: -New
>
> drivers/pci/pci.c | 3 +
On 12/07/2017 05:45 PM, Maran Wilson wrote:
>
> Juergen also had a suggestion to split the different hypervisor types
> early and use a common set of service functions instead of special casing
> xen_guest everywhere.
>
> There are certainly less special cases in this version of the patch, but
> if
Thanks for taking a look Jan. More below...
On 12/8/2017 12:49 AM, Jan Beulich wrote:
On 07.12.17 at 23:45, wrote:
The start info structure that is defined as part of the x86/HVM direct
boot ABI and used for starting Xen PVH guests would be more versatile if
it also included a way to efficient
flight 116958 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
flight 116965 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116965/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116935
test-armhf-armhf-libvirt-raw 13 saveresto
flight 116947 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
115643
test-amd64-am
flight 116954 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116954/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116861
REGR. vs. 116754
Test
flight 116952 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116952/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 116891
Tests which did not succeed
On Fri, Dec 8, 2017 at 5:42 AM, Razvan Cojocaru
wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
> On 24.10.17 at 12:19, wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart
>>>
Hi,
On 06/12/17 12:27, Julien Grall wrote:
On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
On Thu, 23 Nov 2017, Julien Grall wrote:
Hi Andrew,
On 23/11/17 18:49, Andrew Cooper wrote:
On 23/11/17 18:32, Julien Grall wrote:
This new function will be used in a follow-up patch to copy data to
Hi Stefano,
On 07/12/17 23:01, Stefano Stabellini wrote:
On Wed, 6 Dec 2017, Julien Grall wrote:
Hi Stefano,
On 12/06/2017 01:22 AM, Stefano Stabellini wrote:
On Thu, 23 Nov 2017, Julien Grall wrote:
The only differences between copy_to_guest and access_guest_memory_by_ipa
are:
- The l
Hi Stefano,
On 07/12/17 23:05, Stefano Stabellini wrote:
On Wed, 6 Dec 2017, Julien Grall wrote:
From: Julien Grall
When system registers are not enabled, all the access to them will trap
^ accesses
in EL2. In Xen, system registers will be ena
Hi,
Ping?
Cheers,
On 29/11/17 17:46, Julien Grall wrote:
The value of the macro HCR_SYSREG is not surrounded by (). This means
the behavior may change depend on how it is used.
Thanksfully recent GCC will issue a warning for that.
Signed-off-by: Julien Grall
---
I am not aware of any "bad
Hi,
On 29/11/17 18:12, Stefano Stabellini wrote:
On Wed, 29 Nov 2017, Julien Grall wrote:
Per the device-tree specific [1], when the property #address-cells
and #size-cells are not present, the default value should be resp. 1
and 2.
[1]
https://www.devicetree.org/downloads/devicetree-specifi
In case the rsdp address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
V3: use a generic retrieval function with a __weak annotated default
function (Ingo Molnar)
---
arch
Xen PVH guests receive the address of the RSDP table from Xen. In order
to support booting a Xen PVH guest via Grub2 using the standard x86
boot entry we need a way for Grub2 to pass the RSDP address to the
kernel.
For this purpose expand the struct setup_header to hold the physical
address of the
When booted via the special PVH entry save the RSDP address set in the
boot information block in struct boot_params. This will enable Xen to
locate the RSDP at an arbitrary address.
Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
which should have been 0x020c.
Signed-off-b
In the non-EFI boot path the ACPI RSDP table is currently found via
either EBDA or by searching through low memory for the RSDP magic.
This requires the RSDP to be located in the first 1MB of physical
memory. Xen PVH guests, however, get the RSDP address via the start of
day information block.
In
The boot loader version reported via sysfs is wrong in case of the
kernel being booted via the Xen PVH boot entry. it should be 2.12
(0x020c), but it is reported to be 2.18 (0x0212).
As the current way to set the version is error prone use the more
readable variant (2 << 8) | 12.
Cc: # 4.12
Sign
On 05/12/17 18:42, Julien Grall wrote:
Hi Ian,
On 05/12/17 18:41, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [OSSTEST PATCH] linux-arm-xen: Get
from shared arm/linux.git xenbits tree"):
On Tue, 5 Dec 2017, Julien Grall wrote:
Acked-by: Julien Grall
Acked-by: Stefano Stabellini
On 08/12/17 08:03, Tim Deegan wrote:
Hi,
Hi Tim,
Somehow your e-mail was marked as spam by gmail.
At 12:58 + on 06 Dec (1512565090), Julien Grall wrote:
On 12/06/2017 12:28 PM, George Dunlap wrote:
2. It sounds like rather than using PoD, you could use the
"misconfigured p2m table" tec
On 08/12/17 12:17, Jan Beulich wrote:
> Unconditionally reporting a value seen on the P4 or older invokes
> functionality like io_apic_get_unique_id() on 32-bit builds, resulting
> in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what
> that function does would be the hypervisor's re
On 12/08/2017 02:18 PM, Jan Beulich wrote:
On 24.10.17 at 12:19, wrote:
>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>> hence with the original altp2m design, where domains are
Hi, Jan
On Thu, Dec 7, 2017 at 3:57 PM, Jan Beulich wrote:
On 07.12.17 at 14:50, wrote:
>> On Thu, Dec 7, 2017 at 10:57 AM, Jan Beulich wrote:
>> On 06.12.17 at 20:23, wrote:
On Wed, Dec 6, 2017 at 7:01 PM, Jan Beulich wrote:
On 25.07.17 at 19:26, wrote:
>> @@ -175
>>> On 24.10.17 at 12:19, wrote:
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access right
Hi Jan
On Fri, Dec 8, 2017 at 10:07 AM, Jan Beulich wrote:
On 07.12.17 at 21:31, wrote:
>> Have questions which need to be clarified:
>>
>> If I understood correctly, new variant of set_px_pminfo is going to
>> have an extra "flag" argument, since
>> struct processor_performance doesn't hav
On 08/12/17 12:26, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> On 08/12/17 08:05, Ingo Molnar wrote:
>>>
>>> * Juergen Gross wrote:
>>
>> ...
>>
>>> acpi_physical_address acpi_arch_get_root_pointer(void)
>>> {
>>> return boot_params.hdr.acpi_rsdp_addr;
>>> }
>>>
>>> 4)
>>>
>>> Add th
* Juergen Gross wrote:
> On 08/12/17 08:05, Ingo Molnar wrote:
> >
> > * Juergen Gross wrote:
>
> ...
>
> > acpi_physical_address acpi_arch_get_root_pointer(void)
> > {
> > return boot_params.hdr.acpi_rsdp_addr;
> > }
> >
> > 4)
> >
> > Add this to arch/x86/include/asm/acpi.h:
> >
> >
Unconditionally reporting a value seen on the P4 or older invokes
functionality like io_apic_get_unique_id() on 32-bit builds, resulting
in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what
that function does would be the hypervisor's responsibility anyway, so
makes no sense to be u
On 08/12/17 08:05, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
...
> acpi_physical_address acpi_arch_get_root_pointer(void)
> {
> return boot_params.hdr.acpi_rsdp_addr;
> }
>
> 4)
>
> Add this to arch/x86/include/asm/acpi.h:
>
> extern acpi_physical_address acpi_arch_get_root_pointer
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 07 December 2017 06:57
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> xen-de...@lists.xen.org; Jan Beulich ; Ian Jackson
>
> Subject: Re: [RFC Patch v4
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 December 2017 14:14
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap ;
> Tim (Xen.org)
> Subject: [PATCH v3 19/25] x86emul: tell cmpxchg hook whether LOCK is in
> effect
>
> This is necessa
On 12/07/2017 07:21 PM, Marc Zyngier wrote:
> On 07/12/17 18:06, George Dunlap wrote:
>> On 12/07/2017 04:58 PM, Marc Zyngier wrote:
>>> On 07/12/17 16:44, George Dunlap wrote:
On 12/07/2017 04:04 PM, Julien Grall wrote:
> Hi Jan,
>
> On 07/12/17 15:45, Jan Beulich wrote:
>
flight 116949 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 116145
test-amd64-amd64-xl-q
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 December 2017 14:18
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH v3 23/25] x86/HVM: make use of new read-modify-write
> emulator hook
>
> ..., at least as far as curre
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 December 2017 14:17
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH v3 22/25] x86/HVM: do actual CMPXCHG in
> hvmemul_cmpxchg()
>
> ..., at least as far as currently poss
flight 72526 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72526/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail
like 72505
test-armhf-armhf-
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.15-rc3-tag
xen: fixes for 4.15-rc3
Those are just two small fixes for the nev pvcalls frontend driver.
Thanks.
Juergen
drivers/xen/pvcalls-front.c | 4 +++-
1 file changed, 3 in
>>> On 07.12.17 at 23:21, wrote:
> Due to the complexity with the PCI lock we cannot do the reset when a
> device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
> as the pci_[slot|bus]_reset also takes the same lock resulting in a
> dead-lock.
It took me a moment to figure t
On 08/12/17 09:48, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
+Offset/size: 0x268/8
+Protocol: 2.14+
+
+ This field can be set by the boot loader to tell the kernel the
+ physical address of the ACPI RSDP table.
+
+ A value of 0 indicates the kerne
>>> On 07.12.17 at 23:45, wrote:
> The start info structure that is defined as part of the x86/HVM direct
> boot ABI and used for starting Xen PVH guests would be more versatile if
> it also included a way to efficiently pass information about the memory
> map to the guest.
>
> That way Xen PVH g
* Juergen Gross wrote:
> >> +Offset/size: 0x268/8
> >> +Protocol: 2.14+
> >> +
> >> + This field can be set by the boot loader to tell the kernel the
> >> + physical address of the ACPI RSDP table.
> >> +
> >> + A value of 0 indicates the kernel should fall back to the standard
> >> + m
On 08/12/17 08:22, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> When booted via the special PVH entry save the RSDP address set in the
>> boot information block in struct boot_params. This will enable Xen to
>> locate the RSDP at an arbitrary address.
>>
>> Set the boot loader version to 2
On 08/12/17 08:16, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> Xen PVH guests receive the address of the RSDP table from Xen. In order
>> to support booting a Xen PVH guest via grub2 using the standard x86
>> boot entry we need a way fro grub2 to pass the RSDP address to the
>> kernel.
>>
* Jan Beulich wrote:
> >>> On 08.12.17 at 08:16, wrote:
> > Also, a more fundamental question: why doesn't Xen use EFI to hand over
> > hardware configuration details?
>
> Iirc the main purpose of the change here is to allow booting PVH
> (guest or Dom0) with Grub2 in the middle. PVH, at leas
>>> On 08.12.17 at 08:16, wrote:
> Also, a more fundamental question: why doesn't Xen use EFI to hand over
> hardware configuration details?
Iirc the main purpose of the change here is to allow booting PVH
(guest or Dom0) with Grub2 in the middle. PVH, at least for the
time being, is something t
On 08/12/17 08:05, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> In case the rsdp address in struct boot_params is specified don't try
>> to find the table by searching, but take the address directly as set
>> by the boot loader.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/acpi/o
Hi,
At 02:31 -0700 on 06 Dec (1512527481), Jan Beulich wrote:
> >>> On 30.11.17 at 10:10, wrote:
> > i.e. the guest specified a runstate area address which has a non-present
> > mapping in the page tables [EC=0002 CR2=88003d405220], but that's
> > not something the hypervisor needs to be conc
>>> On 07.12.17 at 21:31, wrote:
> Have questions which need to be clarified:
>
> If I understood correctly, new variant of set_px_pminfo is going to
> have an extra "flag" argument, since
> struct processor_performance doesn't have "flag" field (it contains
> "state" field instead, which has yet
Hi,
At 12:58 + on 06 Dec (1512565090), Julien Grall wrote:
> On 12/06/2017 12:28 PM, George Dunlap wrote:
> > 2. It sounds like rather than using PoD, you could use the
> > "misconfigured p2m table" technique that x86 uses: set bits in the p2m
> > entry which cause a specific kind of HAP fault
71 matches
Mail list logo
