[Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

>>> 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

[Xen-devel] [seabios test] 116603: regressions - FAIL

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

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

>>> 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 >

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

>>> 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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

> -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:

[Xen-devel] Xen Security Advisory 247 - Missing p2m error checking in PoD code

-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 =

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

> -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:

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

>>> 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 >>

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

> -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:

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

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.

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

> -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

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

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 > --- >

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

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.

[Xen-devel] [distros-debian-snapshot test] 72497: tolerable FAIL

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

[Xen-devel] [PATCH 0/3] x86: make rsdp address accessible via boot params

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-devel] [PATCH 1/3] x86/boot: add acpi rsdp address to setup_header

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

[Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

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

Re: [Xen-devel] [PATCH v4 1/7] x86/msr: add Raw and Host domain policies

>>> 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

Re: [Xen-devel] [PATCH v4 4/7] x86/msr: add VMX MSRs into HVM_max domain policy

>>> 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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 1/6] machine: Replace has_dynamic_sysbus with list of allowed devices

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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

>>> 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

[Xen-devel] [PATCH] xen/arm: domain_builder: irq sanity check logic fix

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

[Xen-devel] [PATCH v14 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

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

[Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

...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

[Xen-devel] [linux-linus test] 116592: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 116621: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

>>> 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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

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. > >> >

Re: [Xen-devel] [PATCH v4 5/7] x86/cpuid: update signature of hvm_cr4_guest_valid_bits()

>>> 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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

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

[Xen-devel] [PATCH v14 02/11] x86/hvm/ioreq: simplify code and use consistent naming

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

[Xen-devel] [PATCH v14 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

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

[Xen-devel] [PATCH v14 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

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

Re: [Xen-devel] [PATCH v4 3/7] x86/msr: read VMX MSRs values into Raw policy

>>> 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, >

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

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

Re: [Xen-devel] [PATCH] arm64: ITS: fix cacheability adjustment

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.

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

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

Re: [Xen-devel] [PATCH] xen/arm: domain_builder: irq sanity check logic fix

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

[Xen-devel] [seabios test] 116616: regressions - FAIL

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

[Xen-devel] [qemu-mainline test] 116610: regressions - FAIL

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

Re: [Xen-devel] [PATCH] arm64: ITS: fix cacheability adjustment

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

[Xen-devel] [xen-unstable test] 116614: FAIL

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

[Xen-devel] [xen-unstable-smoke test] 116650: regressions - trouble: blocked/broken/pass

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

Re: [Xen-devel] [PATCH 0/3] x86: make rsdp address accessible via boot params

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

[Xen-devel] [xen-4.5-testing test] 116622: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 116655: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 116645: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 116635: tolerable all pass - PUSHED

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

[Xen-devel] [xen-4.9-testing test] 116619: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

>>> 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 (

Re: [Xen-devel] [PATCH 7/9] x86/vvmx: Use correct sizes when reading operands

>>> 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

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

>>> 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; >>> +

Re: [Xen-devel] [PATCH 9/9] x86/vvmx: Use hvm_copy_{to, from}_guest_virt() to read operands

>>> 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; > -

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-libvirt-pair

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

[Xen-devel] [libvirt test] 116607: tolerable all pass - PUSHED

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

[Xen-devel] [xen-unstable-smoke test] 116639: regressions - FAIL

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