flight 116655 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 116635
Tests which
On 28/11/17 22:03, Rafael J. Wysocki wrote:
> On Tue, Nov 28, 2017 at 10:43 AM, Juergen Gross wrote:
>> 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
flight 116622 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116622/
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. 116356
Regressions
flight 116650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5
flight 116645 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 116635
Tests which
flight 116619 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116619/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail blocked in
116463
flight 116639 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 116635
Tests which
flight 116614 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116614/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm broken in 116596
flight 116616 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116616/
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 did not
flight 116635 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116635/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Tue, Nov 28, 2017 at 12:00 PM, Andrew Cooper
wrote:
> On 28/11/17 18:06, Tamas K Lengyel wrote:
>> From: Tamas K Lengyel
>>
>> Currently the built-in XSM policy only gets used if there is no other policy
>> specified during boot. In this patch
Hi Stewart,
On 11/28/2017 02:42 PM, Stewart Hildebrand wrote:
It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand
Whoops. Well
On 11/28/2017 02:05 PM, Andre Przywara wrote:
Hi,
Hi Andre,
Sorry someone I skipped that patch :/.
On 16/11/17 12:02, Andre Przywara wrote:
If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well.
On 28/11/17 18:06, Tamas K Lengyel wrote:
> From: Tamas K Lengyel
>
> Currently the built-in XSM policy only gets used if there is no other policy
> specified during boot. In this patch we add a Kconfig option to specify to
> only
> use built-in policy during boot. This is
On 11/28/2017 04:12 AM, Christian König wrote:
>
>
> How about the attached patch? It limits the newly added MMIO space to
> the upper 256GB of the address space. That should still be enough for
> most devices, but we avoid both issues with Xen dom0 as most likely
> problems with memory hotplug as
On 11/28/2017 01:06 PM, Tamas K Lengyel wrote:
From: Tamas K Lengyel
Currently the built-in XSM policy only gets used if there is no other policy
specified during boot. In this patch we add a Kconfig option to specify to only
use built-in policy during boot. This is
Hi
On Sat, Nov 25, 2017 at 4:16 PM, Eduardo Habkost wrote:
> The existing has_dynamic_sysbus flag makes the machine accept
> every user-creatable sysbus device type on the command-line.
> Replace it with a list of allowed device types, so machines can
> easily accept some
>>> On 18.10.17 at 10:27, wrote:
> With the new cpuid infrastructure there is a domain-wide struct cpuid
> policy and there is no need to pass a separate struct vcpu * into
> hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
> domain * instead and
>>> On 18.10.17 at 10:27, wrote:
> +static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)
> +{
> +if ( !cpu_has_vmx )
> +return;
> +
> +dp->vmx.basic.raw = host_msr_domain_policy.vmx.basic.raw;
> +
> +dp->vmx.pinbased_ctls.raw
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -32,6 +32,37 @@ struct msr_domain_policy __read_mostly
> raw_msr_domain_policy,
> struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
>
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies
flight 116621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 116592 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 115643
>>> On 18.10.17 at 10:27, wrote:
> Raw policy contains the actual values from H/W MSRs. PLATFORM_INFO msr
> needs to be read again because probe_intel_cpuid_faulting() records
> the presence of X86_FEATURE_CPUID_FAULTING but not the presence of msr
> itself (if cpuid
It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2
>>> On 28.11.17 at 13:41, wrote:
> On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
>> >>> On 27.11.17 at 16:41, wrote:
>> > If it is possible we would like to have the Xen image higher than the
>> > booloader put it and certainly do
On Tue, Nov 28, 2017 at 07:02:01AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 14:53, wrote:
> > On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 13:47, wrote:
> >> > Then all cases should be covered.
> >>
>
Hi,
On 16/11/17 12:02, Andre Przywara wrote:
> If the host GICv3 redistributor reports that the pending table cannot
> use shareable memory, we try to drop the cacheability attributes as
> well. However we fail horribly in doing computer science 101 bit
> masking, effectively clearing the whole
flight 116610 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
116533
Tests
>>> On 28.11.17 at 14:53, wrote:
> On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 13:47, wrote:
>> > Then all cases should be covered.
>>
>> I don't think that's going to be enough: Once Xen gets moved,
>> the
On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 13:47, wrote:
> > On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 12:32, wrote:
> >> > I have a feeling that you can trigger
flight 72497 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72497/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like
72475
On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
> >>> On 27.11.17 at 16:41, wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation.
>>> On 28.11.17 at 12:58, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 28 November 2017 11:31
>> To: 'Jan Beulich'
>> Cc: Andrew Cooper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-247
version 2
Missing p2m error checking in PoD code
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Am 28.11.2017 um 11:53 schrieb Jan Beulich:
On 28.11.17 at 11:17, wrote:
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug
On Mon, Nov 27, 2017 at 04:58:52PM +, Andrew Cooper wrote:
> On 27/11/17 15:41, Daniel Kiper wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation. Otherwise the Xen
>>> On 28.11.17 at 12:06, wrote:
> Yes, it appears that mmio_retry is only set when the underlying emulation
> returned X86EMUL_OKAY but not all reps were completed. If the underlying
> emulation did not return X86EMUL_RETRY then I can't figure out why
>
flight 116603 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116603/
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 did not
Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky:
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
On 11/23/2017 03:11 AM, Christian König wrote:
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 November 2017 11:01
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; Julien Grall
> ; xen-devel
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:40
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE:
On 28/11/17 11:17, Roger Pau Monné wrote:
> On Tue, Nov 28, 2017 at 10:44:00AM +0100, 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.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:17
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE:
On Tue, Nov 28, 2017 at 10:43:59AM +0100, 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
> ---
>
On Tue, Nov 28, 2017 at 10:44:00AM +0100, 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.
>
> Signed-off-by: Juergen Gross
>>> On 28.11.17 at 10:49, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2017 08:29
>> To: xen-devel
>> Cc: Julien Grall ; Andrew Cooper
>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2017 08:29
> To: xen-devel
> Cc: Julien Grall ; Andrew Cooper
> ; Paul Durrant
> Subject:
>>> On 28.11.17 at 10:12, wrote:
> In theory the BIOS would search for address space and won't find
> anything, so the hotplug operation should fail even before it reaches
> the kernel in the first place.
How would the BIOS know what the OS does or plans to do? I
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.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pvh.c | 2 ++
1 file changed, 2
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
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.
For this purpose expand the struct setup_header to hold the physical
address of
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/osl.c | 8
1 file changed, 8 insertions(+)
diff --git
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-pair
testid xen-boot/src_host
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux
flight 116607 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116607/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116520
test-armhf-armhf-libvirt-raw 13
>>> On 26.10.17 at 19:03, wrote:
In the title please use "read/write" or "access".
> @@ -380,17 +383,7 @@ static int operand_read(void *buf, struct vmx_inst_op
> *op,
> return X86EMUL_OKAY;
> }
> else
> -{
> -pagefault_info_t pfinfo;
> -
>>> On 27.11.17 at 19:08, wrote:
> On 27/11/17 17:01, Jan Beulich wrote:
> On 26.10.17 at 19:03, wrote:
>>> +return X86EMUL_OKAY;
>> This and ...
>>
>>> +}
>>> +else
>>> +{
>>> +pagefault_info_t pfinfo;
>>> +
>>> On 26.10.17 at 19:03, wrote:
> * invvpid has a 128-bit memory operand but we only require the VPID value
> which lies in the lower 64 bits.
The memory operand (wrongly) isn't being read at all - I don't
understand the above bullet point for that reason.
> @@ -464,6
>>> On 26.10.17 at 19:03, wrote:
> +static int operand_read(void *buf, struct vmx_inst_op *op,
> +struct cpu_user_regs *regs, unsigned int bytes)
const (twice)
> +{
> +if ( op->type == VMX_INST_MEMREG_TYPE_REG )
> +{
> +switch (
63 matches
Mail list logo