Re: [Xen-devel] QEMU build fixes for Xen-4.11

On 10/05/18 15:54, Anthony PERARD wrote: > Hi Juergen, > > Do you mind if I backport a GCC-8 fix + a fix for a libusb deprecated > function? To to be Xen 4.11. I don't mind at all. Go ahead. Juergen > > GCC-8 fix: >> dump: Fix build with newer gcc >>

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

On 10/05/18 10:33, Roger Pau Monné wrote: > On Wed, May 09, 2018 at 06:12:28PM +0200, Juergen Gross wrote: >> On 09/05/18 18:07, Roger Pau Monne wrote: >>> This prevents page-shattering, by being able to populate the RAM >>> regions below 4GB using 1GB pages, provided the guest memory size is >>>

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

On Thu, May 10, 2018 at 11:02 PM, Boris Ostrovsky wrote: > On 05/10/2018 09:53 AM, Souptick Joarder wrote: >> On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross wrote: >>> On 14/04/18 21:15, Souptick Joarder wrote: Use new return type vm_fault_t for

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross wrote: > On 14/04/18 21:15, Souptick Joarder wrote: >> Use new return type vm_fault_t for fault handler >> in struct vm_operations_struct. >> >> Signed-off-by: Souptick Joarder >> Reviewed-by: Matthew Wilcox

[Xen-devel] [qemu-mainline test] 122645: FAIL

flight 122645 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122645/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken in 122629

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

On 10/05/2018, 14:03, "George Dunlap" wrote: On 05/10/2018 12:38 PM, George Dunlap wrote: > On 05/04/2018 09:36 AM, Lars Kurth wrote: >> The tool covers step 2 of the following workflow >> >> Step 1: git format-patch ... -o ... >> Step 2:

[Xen-devel] [linux-4.14 test] 122644: FAIL

flight 122644 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122644/ 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 122572

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

On Thu, 10 May 2018, Praveen Kumar wrote: > > Yeah, you are right. It looks like turning Dom0 into a DomU is not good > > enough. Maybe for this option to be viable we would actually have to > > terminate (or pause and never unpause?) dom0 after boot. > > Just a thought ! > How about keeping Dom0

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

On 05/10/2018 09:53 AM, Souptick Joarder wrote: > On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross wrote: >> On 14/04/18 21:15, Souptick Joarder wrote: >>> Use new return type vm_fault_t for fault handler >>> in struct vm_operations_struct. >>> >>> Signed-off-by: Souptick Joarder

[Xen-devel] [PATCH 0/5] PVH MTRR initial state

Hello, The following patches set a sane initial MTRR state for both Dom0 and DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH for DomU the default MTRR type is set to write-back. This should avoid guests having to setup some kind of MTRR state in order to boot. Thanks,

[Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

Provided to both Dom0 and DomUs. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall

[Xen-devel] [PATCH 4/5] libxc/pvh: set default MTRR type to write-back

And enable MTRR. This allows to provide a sane initial MTRR state for PVH DomUs. This will have to be expanded when pci-passthrough support is added to PVH guests, so that MMIO regions of devices are set as UC. Note that initial MTRR setup is done by hvmloader for HVM guests, that's not used by

[Xen-devel] [PATCH 2/5] hvm/mtrr: use the hardware number of variable ranges for Dom0

Expand the size of the variable ranges array to match the size of the underlying hardware, this is a preparatory change for copying the hardware MTRR state for Dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

Copy the state found on the hardware when creating a PVH Dom0. Since the memory map provided to a PVH Dom0 is based on the native one using the same set of MTRR ranges should provide Dom0 with a sane MTRR state without having to manually build it in Xen. Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote: > Regardless of the fact that the notifier returns an error or not, I > believe it would be good and safe to set priority and document that > priority zero would cause racing issue in the scenario I debugged > today. I'm pretty sure that

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, 2018-05-10 at 17:02 +0100, Julien Grall wrote: > On 10/05/18 16:49, Mirela Simonovic wrote: > > Regardless of the fact that the notifier returns an error or not, I > > believe it would be good and safe to set priority and document that > > priority zero would cause racing issue in the

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, 2018-05-10 at 16:13 +0100, Julien Grall wrote: > On 10/05/18 16:00, Mirela Simonovic wrote: > > > If you add your callback to CPU_UP_PREPARE, instead than to > > > CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without > > > having > > > to fiddle with priorities. > > This

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

On Thu, 10 May 2018, Olaf Hering wrote: > Am Wed, 9 May 2018 14:43:17 -0700 (PDT) > schrieb Stefano Stabellini : > > > 512b109ec962 is a very old commit: why is it causing problems to Xen > > 4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I > > might be

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On 10/05/18 16:49, Mirela Simonovic wrote: Hi Julien, Hi, On Thu, May 10, 2018 at 5:13 PM, Julien Grall wrote: On 10/05/18 16:00, Mirela Simonovic wrote: Hi Dario, On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli wrote: On Thu, 2018-05-10

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi Julien, On Thu, May 10, 2018 at 5:13 PM, Julien Grall wrote: > > > On 10/05/18 16:00, Mirela Simonovic wrote: >> >> Hi Dario, >> >> On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli >> wrote: >>> >>> On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi Dario, On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli wrote: > On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote: >> On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic >> >> > Please take a look at function cpu_schedule_callback in schedule.c. >> > Within switch,

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On 10/05/18 15:12, Mirela Simonovic wrote: Hi Julien, On Thu, May 10, 2018 at 3:29 PM, Julien Grall wrote: Hi, On 05/10/2018 02:24 PM, Mirela Simonovic wrote: On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic wrote: I have tested

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote: > On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic > > > Please take a look at function cpu_schedule_callback in schedule.c. > > Within switch, case CPU_DEAD doesn't have a break, causing the > > bellow > > CPU_UP_CANCELED to execute as

[Xen-devel] QEMU build fixes for Xen-4.11

Hi Juergen, Do you mind if I backport a GCC-8 fix + a fix for a libusb deprecated function? To to be Xen 4.11. GCC-8 fix: > dump: Fix build with newer gcc > https://git.qemu.org/?p=qemu.git;a=commit;h=84c868f6b8f8c1be9d3d65df93cf00b30821401c libusb fix: > Fix libusb-1.0.22 deprecated

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, 2018-05-10 at 13:57 +0200, Mirela Simonovic wrote: > Hi, > > +Dario > Thanks. > On Wed, May 9, 2018 at 6:32 PM, Julien Grall > wrote: > > If there is a bug in the scheduler it should be fixed rather trying > > to > > workaround with a panic in the code. If you

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi, On 05/10/2018 02:24 PM, Mirela Simonovic wrote: On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic wrote: I have tested the tuned scenario where enabling capabilities fails - the erroneous CPU is stopped/powered down and the system continues to work fine

Re: [Xen-devel] [PATCH v2 2/3] checkpatch: generalize xen handle matching in the list of types

On 05/10/2018 04:15 AM, Paul Durrant wrote: All the xen stable APIs define handle types of the form: _handle and some define additional handle types of the form: __handle Maybe worth mentioning that always has a 'xen' prefix, and/or spelling it: xen_handle xen__handle Examples of

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic wrote: > Hi, > > +Dario > > On Wed, May 9, 2018 at 6:32 PM, Julien Grall wrote: >> >> >> On 09/05/18 16:48, Mirela Simonovic wrote: >>> >>> Hi Julien, >> >> >> Hi Mirela, >> >> >>> On Mon, Apr

[Xen-devel] [xen-4.10-testing test] 122643: trouble: blocked/broken/fail/pass

flight 122643 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122643/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken

Re: [Xen-devel] [SVM] Adding page access bits

On 10/05/18 13:59, Alexandru Stefan ISAILA wrote: > Hello, > > We want to add the page access functionality to the SVM code. We have > been trying to add 4 bits in the pte but all seem to be taken. > > Is there a way to accommodate them in the 24 bit flag mask? > > I think it can be done by moving

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

On 05/10/2018 12:38 PM, George Dunlap wrote: > On 05/04/2018 09:36 AM, Lars Kurth wrote: >> The tool covers step 2 of the following workflow >> >> Step 1: git format-patch ... -o ... >> Step 2: ./scripts/add_maintainers.pl -d >> This overwrites *.patch files in >> Step 3: git

[Xen-devel] [SVM] Adding page access bits

Hello, We want to add the page access functionality to the SVM code. We have been trying to add 4 bits in the pte but all seem to be taken. Is there a way to accommodate them in the 24 bit flag mask? I think it can be done by moving the 4 protection key field bits from 22:19 to 23:30 so we can

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi, +Dario On Wed, May 9, 2018 at 6:32 PM, Julien Grall wrote: > > > On 09/05/18 16:48, Mirela Simonovic wrote: >> >> Hi Julien, > > > Hi Mirela, > > >> On Mon, Apr 30, 2018 at 6:09 PM, Julien Grall >> wrote: >>> >>> Hi Mirela, >>> >>> >>> On

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On Wed, May 09, 2018 at 04:11:39PM +0100, Roger Pau Monné wrote: > On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote: > > On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: > > > On 09/05/18 11:21, Roger Pau Monne wrote: > > > I'm not sure that setting the default MTRR

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

On 05/10/2018 12:38 PM, George Dunlap wrote: > --patchcc (top|commit|comment|none) | -p (top|commit|comment|none) > > Insert CC lines into *.patch files in the specified location. > See LOCATIONS for a definition of the various locations. > > The default is `top`. > > --covercc

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

On 05/04/2018 09:36 AM, Lars Kurth wrote: > The tool covers step 2 of the following workflow > > Step 1: git format-patch ... -o ... > Step 2: ./scripts/add_maintainers.pl -d > This overwrites *.patch files in > Step 3: git send-email -to xen-devel@lists.xenproject.org >

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

On Wed, May 09, 2018 at 05:07:12PM +0100, Roger Pau Monne wrote: > This prevents page-shattering, by being able to populate the RAM > regions below 4GB using 1GB pages, provided the guest memory size is > set to a multiple of a GB. > > Note that there are some special and ACPI pages in the MMIO

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

On Tue, May 08, 2018 at 01:31:43PM +0200, Olaf Hering wrote: > It is unclear why that was never noticed in xen-4.10, qemu-2.9 did not have > that bug. > Also, if a KVM or Xen guest is migrated should make zero difference for the > qcow2 driver... Hi Olaf, I did try to fix a migration related

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

On Thu, May 10, 2018 at 10:43:26AM +0100, George Dunlap wrote: > On Wed, May 9, 2018 at 5:07 PM, Roger Pau Monne wrote: > > This prevents page-shattering, by being able to populate the RAM > > regions below 4GB using 1GB pages, provided the guest memory size is > > set to a

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

On 10/05/18 10:26, Kang, Luwei wrote: > Here is a patch-series which adding Processor Trace enabling in XEN > guest. You can get It's software developer manuals from: > https://software.intel.com/sites/default/files/managed/c5/15/archite > ct

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

On Wed, May 9, 2018 at 5:07 PM, Roger Pau Monne wrote: > This prevents page-shattering, by being able to populate the RAM > regions below 4GB using 1GB pages, provided the guest memory size is > set to a multiple of a GB. > > Note that there are some special and ACPI pages

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

> >>> Here is a patch-series which adding Processor Trace enabling in XEN > >>> guest. You can get It's software developer manuals from: > >>> https://software.intel.com/sites/default/files/managed/c5/15/archite > >>> ct ure-instruction-set-extensions-programming-reference.pdf > >>> In Chapter 5

[Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

Xen 4.11 has a new API to directly map guest resources. Among the resources that can be mapped using this API are ioreq pages. This patch modifies QEMU to attempt to use the new API should it exist, falling back to the previous mechanism if it is unavailable. Signed-off-by: Paul Durrant

[Xen-devel] [PATCH v2 1/3] xen-hvm: create separate function for ioreq server initialization

The code is sufficiently substantial that it improves code readability to put it in a new function called by xen_hvm_init() rather than having it inline. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard

[Xen-devel] [PATCH v2 2/3] checkpatch: generalize xen handle matching in the list of types

All the xen stable APIs define handle types of the form: _handle and some define additional handle types of the form: __handle Examples of these are xenforeignmemory_handle and xenforeignmemory_resource_handle. Both of these types will be misparsed by checkpatch if they appear as the first

[Xen-devel] [PATCH v2 0/2] xen-hvm: use new resource mapping API

This series modifies QEMU to use the new guest resource mapping API (available in Xen 4.11+) to map ioreq pages. v2: - Add a patch to checkpatch to avoid misparsing of Xen stable API handles Paul Durrant (3): xen-hvm: create separate function for ioreq server initialization checkpatch:

[Xen-devel] [PATCH] vhpet: check that the set interrupt route is valid

The value written by the guest must be valid according to the mask provided in the interrupt routing capabilities register. If the interrupt is not valid set it to the first valid IRQ in the capabilities field if the timer is enabled, else just clear the field. Also refuse to start any timer that

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

> >>> On 04.05.18 at 05:53, wrote: > >> > Thanks for your clarification. Please correct me if I have > >> > something wrong. Guest may execute an instruction and this > >> > instruction may produce an PT packet save in PT output buffer. An > >> > EPT violation will be

[Xen-devel] [distros-debian-wheezy test] 74702: all pass

flight 74702 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74702/ Perfect :-) All tests in this flight passed as required baseline version: flight 74664 jobs: build-amd64 pass

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

On Wed, May 09, 2018 at 06:12:28PM +0200, Juergen Gross wrote: > On 09/05/18 18:07, Roger Pau Monne wrote: > > This prevents page-shattering, by being able to populate the RAM > > regions below 4GB using 1GB pages, provided the guest memory size is > > set to a multiple of a GB. > > > > Note that

Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen-hvm: use new resource mapping API

> -Original Message- > From: Eric Blake [mailto:ebl...@redhat.com] > Sent: 09 May 2018 18:26 > To: Paul Durrant ; qemu-de...@nongnu.org > Cc: xen-devel@lists.xenproject.org; f...@redhat.com > Subject: Re: [Qemu-devel] [PATCH 0/2] xen-hvm: use new resource mapping >

[Xen-devel] [PATCH -resend 01/27] linkage: new macros for assembler symbols

Introduce new C macros for annotations of functions and data in assembly. There is a long-standing mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support

[Xen-devel] [PATCH -resend 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START. And their ENDPROC's by SYM_FUNC_END. And make sure ENTRY/ENDPROC is not defined on X86_64, given these were the last users. Signed-off-by: Jiri Slaby

[Xen-devel] [PATCH -resend 08/27] x86: assembly, annotate aliases

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy.

[Xen-devel] [PATCH -resend 22/27] x86_64: assembly, change all ENTRY+END to SYM_CODE_*

Here, we change all code which is not marked as functions. In other words, this code has been using END, not ENDPROC. So switch all of this to appropriate new markings SYM_CODE_START and SYM_CODE_END. Signed-off-by: Jiri Slaby Reviewed-by: Boris Ostrovsky

[Xen-devel] [PATCH -resend 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_*

All these are functions which are invoked from elsewhere, but they are not typical C functions. So we annotate them (as global) using the new SYM_CODE_START. All these were not balanced with any END, so mark their ends by SYM_CODE_END, appropriatelly. Signed-off-by: Jiri Slaby

[Xen-devel] [PATCH -resend 21/27] x86_64: assembly, add ENDs to some functions and relabel with SYM_CODE_*

All these are functions which are invoked from elsewhere, but they are not typical C functions. So we annotate them (as global) using the new SYM_CODE_START. All these were not balanced with any END, so mark their ends by SYM_CODE_END, appropriatelly. Signed-off-by: Jiri Slaby

[Xen-devel] [PATCH -resend 19/27] x86: assembly, make some functions local

There is a couple of assembly functions, which are invoked only locally in the file they are defined. In C, we mark them "static". In assembly, annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on ENDPROC/END for a

[Xen-devel] [PATCH -resend 13/27] x86: xen-pvh, annotate data appropriatelly

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros: 8 OBJECT LOCAL DEFAULT6 gdt 000832 OBJECT LOCAL DEFAULT6 gdt_start 0028 0 OBJECT LOCAL DEFAULT6 gdt_end 0028 256 OBJECT LOCAL DEFAULT6 early_stack 0128 0 OBJECT LOCAL DEFAULT6

Re: [Xen-devel] [PATCH v3 06/10] xen/common: Restore IRQ affinity when hotplugging a pCPU

On Fri, 2018-04-27 at 19:12 +0200, Mirela Simonovic wrote: > Non-boot pCPUs are being hot-unplugged during the system suspend to > RAM and hotplugged during the resume. When non-boot pCPUs are > hot-unplugged the interrupts that were targeted to them are migrated > to the boot pCPU. > On suspend,

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Wed, 9 May 2018 14:43:17 -0700 (PDT) schrieb Stefano Stabellini : > 512b109ec962 is a very old commit: why is it causing problems to Xen > 4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I > might be missing some context. It is papering over the real