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

flight 121275 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/121275/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095

Re: [Xen-devel] [PATCH] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage

在 2018/3/26 21:39, Jan Beulich 写道: On 21.03.18 at 03:58, wrote: After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS enabled after their exit. It's not necessory for bootup code to run in low performance with IBRS enabled. On ORACLE

[Xen-devel] [xen-unstable test] 121272: tolerable FAIL - PUSHED

flight 121272 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/121272/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120859 test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [PATCH v3 0/5] sndif: add explicit back and front synchronization

Hi, Konrad! Could you please review? Thank you, Oleksandr On 03/21/2018 09:25 AM, Oleksandr Andrushchenko wrote: On 03/21/2018 09:20 AM, Takashi Iwai wrote: On Wed, 21 Mar 2018 08:15:36 +0100, Oleksandr Andrushchenko wrote: On 03/20/2018 10:22 PM, Takashi Iwai wrote: On Mon, 19 Mar 2018

[Xen-devel] [ovmf test] 121281: all pass - PUSHED

flight 121281 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/121281/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dd190645eb43424706eb1709d0032c69a1935d9f baseline version: ovmf

[Xen-devel] [PATCH v2] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage

After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS enabled after their exit. It's not necessory for bootup code to run in low performance with IBRS enabled. On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpus), we observed an 200s+ delay in construct_dom0. By initializing

Re: [Xen-devel] possible I/O emulation state machine issue

>>> On 23.03.18 at 14:41, wrote: > So somehow it appears the vcpu got back into guest and executed the next > instruction whilst there was pending I/O. Two new pieces of information, in case either rings a bell: The issue appears to never occur in hap=0 mode. After

Re: [Xen-devel] [PATCH 4/3] README: document that qemu-trad wants libpci

>>> On 25.03.18 at 16:26, wrote: > qemu-traditional wants libpci from pciutils for supporting PCI > passthrough. Iirc it builds fine without, disabling respective code. Hence I don't think this fully fits the other (strict) requirements. Jan

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

On 26/03/18 12:13, Jan Beulich wrote: On 26.03.18 at 10:55, wrote: >> On 26/03/18 10:28, Jan Beulich wrote: >> On 26.03.18 at 08:49, wrote: On 23/03/18 16:58, Jan Beulich wrote: On 23.03.18 at 15:11, wrote: >> On

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote: > > > My apologies, but I found a few more things that look strange and should > > be cleaned up. Sorry for this iterative review approach, but I think we're > > slowly getting there. > Thank you for reviewing! > > Cheers,

[Xen-devel] [linux-4.1 test] 121231: regressions - FAIL

flight 121231 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121231/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 118294 build-i386-pvops

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Mirela, Good to know that you are working suspend/resume support. Currently we are also trying to support this on i.MX8, just wonder do you have any open source available to support suspend to ram? > + > +Suspend to RAM (in the following text 'suspend') for ARM in Xen should > +be

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

On 26/03/18 05:43, Manish Jaggi wrote: > > > On 03/23/2018 12:28 PM, Julien Grall wrote: >> (Sorry for the formatting) >> >> On 23 Mar 2018 14:46, "Manish Jaggi" > > wrote: >> >> >> >> On 03/21/2018 03:26 PM, Julien Grall wrote:

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

>>> On 26.03.18 at 10:55, wrote: > On 26/03/18 10:28, Jan Beulich wrote: > On 26.03.18 at 08:49, wrote: >>> On 23/03/18 16:58, Jan Beulich wrote: >>> On 23.03.18 at 15:11, wrote: > On 23/03/18 14:46, Jan Beulich wrote: >> So in

[Xen-devel] [xen-4.8-testing test] 121210: regressions - FAIL

flight 121210 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121210/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pairbroken in 121083 test-xtf-amd64-amd64-5 50

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

>>> On 26.03.18 at 12:29, wrote: > On 26/03/18 12:13, Jan Beulich wrote: > On 26.03.18 at 10:55, wrote: >>> I can change the scheme to use different values for guest PCIDs >>> with XPTI on, of course. Are you fine with: >>> >>> - XPTI off: PCID 0 = kernel,

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

On 23/03/18 16:58, Jan Beulich wrote: On 23.03.18 at 15:11, wrote: >> On 23/03/18 14:46, Jan Beulich wrote: >>> Valid point. Looking at all present uses of ->arch.cr3, it's probably >>> indeed better the way you have it. However, I'm now wondering >>> about something else:

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

>>> On 26.03.18 at 08:49, wrote: > On 23/03/18 16:58, Jan Beulich wrote: > On 23.03.18 at 15:11, wrote: >>> On 23/03/18 14:46, Jan Beulich wrote: So in the end the question is: Why not use just two PCIDs, and allow global pages just like we do now,

Re: [Xen-devel] Sunseting mercurial

>>> On 25.03.18 at 04:46, wrote: > Its been officially 5+ years since Xen has moved to git so I propose we > start thinking about when to retire the mercurial mirrors. At this point > the last stable version to be tracked in mercurial is 4.4 which is long > out of any form of

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

On 26/03/18 10:28, Jan Beulich wrote: On 26.03.18 at 08:49, wrote: >> On 23/03/18 16:58, Jan Beulich wrote: >> On 23.03.18 at 15:11, wrote: On 23/03/18 14:46, Jan Beulich wrote: > So in the end the question is: Why not use just two PCIDs, and

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Sat, Mar 24, 2018 at 08:32:44AM +1000, Alexey G wrote: > On Fri, 23 Mar 2018 13:57:11 + > Paul Durrant wrote: > [...] > >> Few related thoughts: > >> > >> 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on > >> other x86 systems it may be HECBASE

[Xen-devel] [PATCH v6] hvm/svm: Implement Debug events

At this moment the Debug events for the AMD architecture are not forwarded to the monitor layer. This patch adds the Debug event to the common capabilities, adds the VMEXIT_ICEBP then forwards the event to the monitor layer. Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1

Re: [Xen-devel] [PATCH for-4.11 0/3] vpci bugfixes

On Mon, Mar 26, 2018 at 12:21:01PM +0100, Roger Pau Monne wrote: > Hello, > > This tree patches are bugfixes for the vPCI code merged last week. They > where spotted by Coverity. Sorry I've failed to CC the maintainers, will resend. Roger. ___

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

On 03/26/2018 11:18 AM, Daniel Vetter wrote: On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote: My apologies, but I found a few more things that look strange and should be cleaned up. Sorry for this iterative review approach, but I think we're slowly getting there. Thank

[Xen-devel] [xen-4.7-testing test] 121247: tolerable FAIL - PUSHED

flight 121247 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121247/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121093 pass in 121247

Re: [Xen-devel] [PATCH v1.1 for-4.11 1/3] vpci/bars: fix error message

>>> On 26.03.18 at 13:28, wrote: > Error message is incorrectly using map when it should be using > map->map instead. > > Reported-by: Coverity Coverity ID: 1430811 > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v1 05/15] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

Hi Julien, On 03/21/2018 02:08 PM, Julien Grall wrote: On 03/16/2018 11:58 AM, Manish Jaggi wrote: This patch is ported to xen from linux commit: f8b630bc542e0368886ae193d3519c832b270359 Add a handler for reading/writing the guest's view of the ICC_IGRPEN1_EL1 The wrapping looks wrong.

Re: [Xen-devel] [PATCH 01/12] checkpatch: Add xendevicemodel_handle to the list of types

Paolo Bonzini writes ("Re: [PATCH 01/12] checkpatch: Add xendevicemodel_handle to the list of types"): > On 08/03/2018 20:02, Ian Jackson wrote: > > This avoids checkpatch misparsing (as statements) long function > > definitions or declarations, which sometimes start with constructs > > like

Re: [Xen-devel] [PATCH 16/20] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()

>>> On 19.03.18 at 20:13, wrote: > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -2078,7 +2078,8 @@ static void __init find_gnttab_region(struct domain *d, > * enough space for a large grant table > */ > kinfo->gnttab_start

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

On 26/03/18 12:43, Jan Beulich wrote: On 26.03.18 at 12:29, wrote: >> On 26/03/18 12:13, Jan Beulich wrote: >> On 26.03.18 at 10:55, wrote: I can change the scheme to use different values for guest PCIDs with XPTI on, of course. Are you fine

Re: [Xen-devel] broken build

On Sat, Mar 24, 2018 at 04:20:14PM -0400, Jacob Embree wrote: > This is a followup to https://xen.markmail.org/thread/6bzbtbbprexrli2f > > According to  > https://stackoverflow.com/questions/20369672/undefined-reference-to-dlsym > a couple more flags are needed. > > commit

Re: [Xen-devel] [PATCH 4/3] README: document that qemu-trad wants libpci

>>> On 26.03.18 at 15:22, wrote: > On 3/26/18 5:18 AM, Jan Beulich wrote: > On 25.03.18 at 16:26, wrote: >>> qemu-traditional wants libpci from pciutils for supporting PCI >>> passthrough. >> >> Iirc it builds fine without, disabling respective code.

Re: [Xen-devel] Sunseting mercurial

On Mon, Mar 26, 2018 at 04:35:40AM -0600, Jan Beulich wrote: > >>> On 25.03.18 at 04:46, wrote: > > Its been officially 5+ years since Xen has moved to git so I propose we > > start thinking about when to retire the mercurial mirrors. At this point > > the last stable version

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

>>> On 26.03.18 at 14:04, wrote: > On 26/03/18 12:43, Jan Beulich wrote: > On 26.03.18 at 12:29, wrote: >>> On 26/03/18 12:13, Jan Beulich wrote: >>> On 26.03.18 at 10:55, wrote: > I can change the scheme to use different values for

[Xen-devel] [PATCH for-4.11 1/3] vpci/bars: fix error message

Error message is incorrectly using map when it should be using map->map instead. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- xen/drivers/vpci/header.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/vpci/header.c

[Xen-devel] [PATCH for-4.11 2/3] vpci/msix: fix incorrect usage of bitmask

The bitmask to clear the low bits of the address field should be ~0xull, the current mask clears both the low and the high bits of the address field, which is a bug. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- xen/drivers/vpci/msix.c | 2 +- 1 file

Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

On 26/03/18 14:19, Jan Beulich wrote: On 26.03.18 at 14:04, wrote: >> On 26/03/18 12:43, Jan Beulich wrote: >> On 26.03.18 at 12:29, wrote: On 26/03/18 12:13, Jan Beulich wrote: On 26.03.18 at 10:55, wrote: >> I can

Re: [Xen-devel] [PATCH v1.1 for-4.11 3/3] vpci/msi: fix size of the vectors fields

>>> On 26.03.18 at 13:28, wrote: > The current size (5bits) is not enough to store the maximum number of > vectors (32), bump it by one bit. > > Note that the size of the struct is still the same. Coverity ID: 1430810 > --- a/xen/include/xen/vpci.h > +++

Re: [Xen-devel] [PATCH v18 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

>>> On 26.03.18 at 14:16, wrote: On 22.03.18 at 12:55, wrote: >> --- a/xen/common/grant_table.c >> +++ b/xen/common/grant_table.c >> @@ -3863,6 +3863,35 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, >> grant_ref_t ref, >> } >> #endif

Re: [Xen-devel] Sunseting mercurial

On Mon, Mar 26, 2018 at 11:56:49AM +0100, Anthony PERARD wrote: > I'll fix the mirror. It's fixed now. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

Hi Marc, I have a query on this patch. The original patch was using these functions so it was ok to make them static. But this patch is not touching the xen vgic code similar to what your patch did. Will it be ok to merge this patch with

Re: [Xen-devel] Sunseting mercurial

>>> On 26.03.18 at 15:18, wrote: > On Mon, Mar 26, 2018 at 11:56:49AM +0100, Anthony PERARD wrote: >> I'll fix the mirror. > > It's fixed now. Thanks a lot! Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 14/20] xen/gnttab: Remove replace_grant_supported()

>>> On 19.03.18 at 20:13, wrote: > It is identical on all architecture, and this is a better overall than fixing > it up to have a proper boolean return value. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH 4/4] drivers/net: Use octal not symbolic permissions

On Fri, Mar 23, 2018 at 03:54:39PM -0700, Joe Perches wrote: > Prefer the direct use of octal for permissions. > > Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace > and some typing. > > Miscellanea: > > o Whitespace neatening around these conversions. > > Signed-off-by: Joe

[Xen-devel] [C stubdom] printf to console not complete

Dear all, This is Lele Ma, a graduate student from The College of William and Mary. I am playing with c-stubdom on Xen-4.9.1 and encountered problems when do printings using printf. It seems that if I print many lines of strings consecutively, many lines would got cut at the tail. Here is an

[Xen-devel] [PATCH for-4.11 0/3] vpci bugfixes

Hello, This tree patches are bugfixes for the vPCI code merged last week. They where spotted by Coverity. Thanks, Roger. Roger Pau Monne (3): vpci/bars: fix error message vpci/msix: fix incorrect usage of bitmask vpci/msi: fix size of the vectors fields xen/drivers/vpci/header.c | 2 +-

[Xen-devel] [PATCH for-4.11 3/3] vpci/msi: fix size of the vectors fields

The current size (5bits) is not enough to store the maximum number of vectors (32), bump it by one bit. Note that the size of the struct is still the same. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- xen/include/xen/vpci.h | 4 ++-- 1 file changed, 2

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> On 22.03.18 at 12:55, wrote: > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -967,6 +967,94 @@ static long xatp_permission_check(struct domain *d, > unsigned int space) > return xsm_add_to_physmap(XSM_TARGET, current->domain, d); > } > > +static

Re: [Xen-devel] [PATCH v18 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

>>> On 22.03.18 at 12:55, wrote: > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -3863,6 +3863,35 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, > grant_ref_t ref, > } > #endif > > +/* caller must hold read or write lock */ > +static

Re: [Xen-devel] [PATCH v1.1 for-4.11 2/3] vpci/msix: fix incorrect usage of bitmask

>>> On 26.03.18 at 13:28, wrote: > The bitmask to clear the low bits of the address field should be > ~0xull, the current mask clears both the low and the high bits > of the address field, which is a bug. > > Reported-by: Coverity > Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v1.1 for-4.11 0/3] vpci bugfixes

>>> On 26.03.18 at 13:28, wrote: > This tree patches are bugfixes for the vPCI code merged last week. They > where spotted by Coverity. Thanks for dealing with them. You having omitted Coverity IDs I suppose the report you've looked at was from the XenServer internal

Re: [Xen-devel] [PATCH] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage

>>> On 21.03.18 at 03:58, wrote: > After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS > enabled after their exit. It's not necessory for bootup code to run in low > performance with IBRS enabled. > > On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20

Re: [Xen-devel] Sunseting mercurial

On 3/26/18 5:35 AM, Jan Beulich wrote: On 25.03.18 at 04:46, wrote: >> Its been officially 5+ years since Xen has moved to git so I propose we >> start thinking about when to retire the mercurial mirrors. At this point >> the last stable version to be tracked in mercurial

Re: [Xen-devel] [PATCH] retire bitkeeper bits

On Sat, Mar 24, 2018 at 09:32:47PM -0500, Doug Goldstein wrote: > While the project could migrate from git to $nextscm, its unlikely that > these bits will ever be useful again. > > Signed-off-by: Doug Goldstein Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v6] hvm/svm: Implement Debug events

>>> On 26.03.18 at 11:43, wrote: > At this moment the Debug events for the AMD architecture are not > forwarded to the monitor layer. > > This patch adds the Debug event to the common capabilities, adds > the VMEXIT_ICEBP then forwards the event to the monitor layer. >

Re: [Xen-devel] [PATCH 4/3] README: document that qemu-trad wants libpci

On 3/26/18 5:18 AM, Jan Beulich wrote: On 25.03.18 at 16:26, wrote: >> qemu-traditional wants libpci from pciutils for supporting PCI >> passthrough. > > Iirc it builds fine without, disabling respective code. Hence I don't > think this fully fits the other (strict)

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

flight 121238 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/121238/ 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] Sunseting mercurial

On Mon, Mar 26, 2018 at 04:35:40AM -0600, Jan Beulich wrote: > >>> On 25.03.18 at 04:46, wrote: > > Its been officially 5+ years since Xen has moved to git so I propose we > > start thinking about when to retire the mercurial mirrors. At this point > > the last stable version

[Xen-devel] [rumprun test] 121264: regressions - FAIL

flight 121264 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/121264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754 build-i386-rumprun

[Xen-devel] [PATCH v1.1 for-4.11 3/3] vpci/msi: fix size of the vectors fields

The current size (5bits) is not enough to store the maximum number of vectors (32), bump it by one bit. Note that the size of the struct is still the same. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George

[Xen-devel] [PATCH v1.1 for-4.11 0/3] vpci bugfixes

Hello, This tree patches are bugfixes for the vPCI code merged last week. They where spotted by Coverity. Version v1.1 is due to the fact that I've failed to Cc the maintainers in v1, sorry for the spam. Thanks, Roger. Roger Pau Monne (3): vpci/bars: fix error message vpci/msix: fix

[Xen-devel] [PATCH v1.1 for-4.11 2/3] vpci/msix: fix incorrect usage of bitmask

The bitmask to clear the low bits of the address field should be ~0xull, the current mask clears both the low and the high bits of the address field, which is a bug. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper

[Xen-devel] [PATCH v1.1 for-4.11 1/3] vpci/bars: fix error message

Error message is incorrectly using map when it should be using map->map instead. Reported-by: Coverity Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

On Mon, Mar 26, 2018 at 09:51:40AM +, Peng Fan wrote: > Hi Mirela, > > Good to know that you are working suspend/resume support. Currently we are > also trying > to support this on i.MX8, just wonder do you have any open source available to > support suspend to ram? > > > + > > +Suspend to

Re: [Xen-devel] [PATCH v18 06/11] x86/hvm/ioreq: add a new mappable resource type...

>>> On 22.03.18 at 12:55, wrote: > ... XENMEM_resource_ioreq_server > > This patch adds support for a new resource type that can be mapped using > the XENMEM_acquire_resource memory op. > > If an emulator makes use of this resource type then, instead of mapping > gfns,

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> On 26.03.18 at 13:41, wrote: On 22.03.18 at 12:55, wrote: >> --- a/xen/include/public/memory.h >> +++ b/xen/include/public/memory.h >> @@ -599,6 +599,59 @@ struct xen_reserved_device_memory_map { >> typedef struct

Re: [Xen-devel] [PATCH v1 04/15] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 03/21/2018 01:41 PM, Julien Grall wrote: Hi Manish, On 03/16/2018 11:58 AM, Manish Jaggi wrote: This patch is ported to xen from linux commit d70c7b31a60f2458f35c226131f2a01a7a98b6cf Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 register, which is located in the

Re: [Xen-devel] [PATCH 13/20] xen/evtchn: Pass max_evtchn_port into evtchn_init()

>>> On 19.03.18 at 20:13, wrote: > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -693,7 +693,9 @@ void __init start_xen(unsigned long boot_phys_offset, > const char *cmdline; > struct bootmodule *xen_bootmodule; > struct domain *dom0; > -

Re: [Xen-devel] [PATCH 15/20] xen/gnttab: Export opt_max_{grant, maptrack}_frames

>>> On 19.03.18 at 20:13, wrote: > This is to facilitate the values being passed in via domain_create(), at which > point the dom0 construction code needs to know them. > > While cleaning up, drop the DEFAULT_* defines, which are only used immediately > adjacent in a

[Xen-devel] [PATCH v2 for-4.11 2/2] vpci: make sure handlers can deal with size == 0

The code is not prepared to handle such case, so just return early. In the debug case add an assert. Reported-by: Coverity Coverity ID: 1430809 Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

Thanks for this update! George Dunlap writes ("[PATCH] docs/qemu-deprivilege: Revise and update with status and future plans"): ... > +# Technical details > + > +## Restrictions done This makes this doc into a mixture of a design doc and a user doc, I think. It might be worth stating the

[Xen-devel] [linux-3.18 test] 121268: regressions - trouble: blocked/broken/fail/pass

flight 121268 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121268/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-armhf-libvirt 5

Re: [Xen-devel] [PATCH 18/20] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value

>>> On 19.03.18 at 20:13, wrote: > Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting > the existing alloc_dom0_vcpu0() function in half. > > As domain_create() doesn't yet set up the vcpu array, the max value is also > passed into

Re: [Xen-devel] [PATCH v1.1 for-4.11 0/3] vpci bugfixes

On Mon, Mar 26, 2018 at 06:39:21AM -0600, Jan Beulich wrote: > >>> On 26.03.18 at 13:28, wrote: > > This tree patches are bugfixes for the vPCI code merged last week. They > > where spotted by Coverity. > > Thanks for dealing with them. You having omitted Coverity IDs I >

Re: [Xen-devel] [PATCH 3/5] libxc: Allow loading of firmware modules for HVM guest

On 21/03/18 15:17, Wei Liu wrote: On Thu, Mar 15, 2018 at 05:31:51PM +, Anoob Soman wrote: modlist, start_info); +for ( i = 0; i < dom->num_modules; i++ ) +{ +struct xc_hvm_firmware_module mod; + +DOMPRINTF("Adding module

Re: [Xen-devel] [PATCH 19/20] xen/domain: Call arch_domain_create() as early as possible in domain_create()

>>> On 19.03.18 at 20:13, wrote: > This is in preparation to set up d->max_cpus and d->vcpu[] in > arch_domain_create(), and allow later parts of domain construction to have > access to the values. I'm not convinced of the allocation to be done in arch_domain_create()

Re: [Xen-devel] [PATCH 4/4] drivers/net: Use octal not symbolic permissions

From: Joe Perches Date: Fri, 23 Mar 2018 15:54:39 -0700 > Prefer the direct use of octal for permissions. > > Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace > and some typing. > > Miscellanea: > > o Whitespace neatening around these conversions. > >

Re: [Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

On 26/03/18 14:19, Manish Jaggi wrote: > Hi Marc, > > I have a query on this patch. The original patch was using these > functions so it was ok to make them static. > But this patch is not touching the xen vgic code similar to what your > patch did. > > Will it be ok to merge this patch with

[Xen-devel] [SVM]NPF page mapping

Hello, We are trying to introduce the Pace Access functionality on SVM. Right now, on the p2m_pt_set_entry() the p2m_access_t is not set and in the p2m_pt_get_entry() it is returned as p2m_access_rwx by default. Could you please suggest some up-to-date documentation on NPT, especially

Re: [Xen-devel] [PATCH 4/5] libxl: Load iPXE ROM from a file

On 21/03/18 15:25, Wei Liu wrote: +LOGE(ERROR, "xc_dom_kernel_file failed"); +goto out; +} +if ((ipxe_filename = libxl__ipxe_path())) { +rc = xc_dom_module_file(dom, ipxe_filename, "ipxe"); +if (rc) { +LOGE(ERROR,

Re: [Xen-devel] [PATCH 17/20] xen/gnttab: Fold grant_table_{create, set_limits}() into grant_table_init()

>>> On 19.03.18 at 20:13, wrote: > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -1808,22 +1808,28 @@ gnttab_grow_table(struct domain *d, unsigned int > req_nr_frames) > return -ENOMEM; > } > > -static int > -grant_table_init(struct

Re: [Xen-devel] [PATCH 2/5] tools/firmware: #define IPXE_PATH

On 21/03/18 15:18, Wei Liu wrote: On Thu, Mar 15, 2018 at 05:31:50PM +, Anoob Soman wrote: --with-system-ipxe allows the user to specify ipxe rom. If this option is given, use system supplied ipxe instead of building and installing our own version Plumbing for using iPXE roms, specified

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

flight 121297 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121297/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 121090 Tests which

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

flight 121301 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121301/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[Xen-devel] [RFC 0/4] libxl: Enable save/restore/migration of a restricted QEMU

The first two patchs fix save of a VM with a restricted QEMU, and the later two patchs try to fix the restore path, but it is still WIP. Checkout the last patch comments for more information. Anthony PERARD (4): libxl: Learned to send FD through QMP to QEMU libxl: Have QEMU save its state to

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Mon, 26 Mar 2018 10:24:38 +0100 Roger Pau Monné wrote: >On Sat, Mar 24, 2018 at 08:32:44AM +1000, Alexey G wrote: [...] >> In fact, the emulated chipset (NB+SB combo without supplemental >> devices) itself is a small part of required emulation. It's >> relatively easy to

[Xen-devel] [RFC 2/4] libxl: Have QEMU save its state to a file descriptor

In case QEMU have restricted access to the system, open the file for it, and QEMU will save its state to this file descritor. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_qmp.c | 38 +- 1 file changed, 37 insertions(+), 1

[Xen-devel] [RFC 3/4] libxl_qmp: Implement query-status command

It check via QMP if QEMU as reach the intended status. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 3 +++ tools/libxl/libxl_qmp.c | 39 +++ 2 files changed, 42 insertions(+) diff --git

[Xen-devel] [RFC 4/4] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

This path is more of a prof of concept reather than a patch as this would break qemu-trad. When qemu is restricted, the qemu on the receiving side cann't write anything to xenstore once the migration is started. So it cann't tell libxl that it is ready to continue running the guest. For libxl,

[Xen-devel] [RFC 1/4] libxl: Learned to send FD through QMP to QEMU

Adding the ability to send a file descriptor from libxl to QEMU via the QMP interface. This will be use with the "add-fd" QMP command. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_qmp.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-)

Re: [Xen-devel] [PATCH v3a 03/39] ARM: GIC: Allow tweaking the active and pending state of an IRQ

On Thu, 22 Mar 2018, Andre Przywara wrote: > When playing around with hardware mapped, level triggered virtual IRQs, > there is the need to explicitly set the active or pending state of an > interrupt at some point. > To prepare the GIC for that, we introduce a set_active_state() and a >

[Xen-devel] [linux-4.9 test] 121270: tolerable FAIL - PUSHED

flight 121270 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121270/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120913 test-amd64-i386-xl-qemut-win7-amd64 17

Re: [Xen-devel] [PATCH v3 08/39] ARM: new VGIC: Add data structure definitions

On Wed, 21 Mar 2018, Andre Przywara wrote: > Add a new header file for the new and improved GIC implementation. > The big change is that we now have a struct vgic_irq per IRQ instead > of spreading all the information over various bitmaps in the ranks. > > We include this new header conditionally

Re: [Xen-devel] [PATCH v3 09/39] ARM: new VGIC: Add accessor to new struct vgic_irq instance

On Thu, 22 Mar 2018, Julien Grall wrote: > Hi Andre, > > On 03/21/2018 04:32 PM, Andre Przywara wrote: > > The new VGIC implementation centers around a struct vgic_irq instance > > per virtual IRQ. > > Provide a function to retrieve the right instance for a given IRQ > > number and (in case of

Re: [Xen-devel] [PATCH v3a 14/39] ARM: new VGIC: Add GICv2 world switch backend

On Thu, 22 Mar 2018, Andre Przywara wrote: > Processing maintenance interrupts and accessing the list registers > are dependent on the host's GIC version. > Introduce vgic-v2.c to contain GICv2 specific functions. > Implement the GICv2 specific code for syncing the emulation state > into the VGIC

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

flight 121306 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121306/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v3 04/39] ARM: GIC: Allow reading pending state of a hardware IRQ

On Wed, 21 Mar 2018, Andre Przywara wrote: > To synchronize level triggered interrupts which are mapped into a guest, > we need to update the virtual line level at certain points in time. > For a hardware mapped interrupt the GIC is the only place where we can > easily access this information. >

Re: [Xen-devel] [PATCH v3 02/39] ARM: GIC: add GIC_INVALID to enum gic_version

On Wed, 21 Mar 2018, Andre Przywara wrote: > The enum gic_version at the moment just contains GIC_V2 and GIC_V3, > where GIC_V2 happens to map to 0. So without having initialised a > variable of that type, we will read back GIC_V2 (when allocated with zeroing > the memory). > To prevent

Re: [Xen-devel] [PATCH v3 07/39] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available

On Wed, 21 Mar 2018, Andre Przywara wrote: > The emulated ARM SBSA UART is using level triggered IRQ semantics, > however the current VGIC can only handle edge triggered IRQs, really. > Disable the existing workaround for this problem in case we have the > new VGIC in place, which can properly

Re: [Xen-devel] [PATCH v3 05/39] ARM: timer: Handle level triggered IRQs correctly

On Wed, 21 Mar 2018, Andre Przywara wrote: > The ARM Generic Timer uses a level-sensitive interrupt semantic. We > easily catch when the line goes high, as this triggers the hardware IRQ. > However we also have to keep track of when the line lowers, as the > emulation depends on it: Upon entering

  1   2   >