Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held

On 04.12.2020 16:09, Julien Grall wrote: > On 04/12/2020 12:01, Jan Beulich wrote: >> On 04.12.2020 12:51, Julien Grall wrote: >>> On 04/12/2020 11:48, Jan Beulich wrote: On 04.12.2020 12:28, Julien Grall wrote: > On 03/12/2020 10:09, Jan Beulich wrote: >> On 02.12.2020 22:10, Julien G

Re: [PATCH] vpci/msix: exit early if MSI-X is disabled

On 06.12.2020 12:15, Roger Pau Monné wrote: > On Thu, Dec 03, 2020 at 02:40:28PM +0100, Jan Beulich wrote: >> On 02.12.2020 09:38, Jan Beulich wrote: >>> On 01.12.2020 18:40, Roger Pau Monne wrote: --- a/xen/drivers/vpci/msix.c +++ b/xen/drivers/vpci/msix.c @@ -357,7 +357,11 @@ stati

Re: [PATCH v2 8/8] xen/arm: Add support for SMMUv3 driver

Hello Stefano, > On 3 Dec 2020, at 6:47 pm, Stefano Stabellini wrote: > > On Thu, 3 Dec 2020, Rahul Singh wrote: >>> On 3 Dec 2020, at 4:13 am, Stefano Stabellini >>> wrote: >>> On Wed, 2 Dec 2020, Julien Grall wrote: On 02/12/2020 02:51, Stefano Stabellini wrote: > On Thu, 26 Nov 202

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: > On 11/13/20 4:51 PM, Jan Beulich wrote: >> On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: >>> On 11/13/20 4:38 PM, Jan Beulich wrote: On 13.11.2020 15:32, Oleksandr Andrushchenko wrote: > On 11/13/20 4:23 PM, Jan Beulich wrote: >>>

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

Marek, On 06.12.20 17:47, Jason Andryuk wrote: On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki wrote: On Fri, Dec 04, 2020 at 01:08:03PM +0100, Christoph Hellwig wrote: On Fri, Dec 04, 2020 at 12:08:47PM +0100, Marek

Re: [PATCH v2 00/17] xen: support per-cpupool scheduling granularity

On 05.12.2020 00:53, Andrew Cooper wrote: > Weirdly, there is a second diagnostic showing up which appears to be > unrelated and non-fatal, but a concerning non-the-less > > mem_access.c: In function 'p2m_mem_access_check': > mem_access.c:227:6: note: parameter passing for argument of type 'const

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On 07.12.20 09:53, Jürgen Groß wrote: Marek, On 06.12.20 17:47, Jason Andryuk wrote: On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki wrote: On Fri, Dec 04, 2020 at 01:08:03PM +0100, Christoph Hellwig wrote: On Fri,

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 12/7/20 10:48 AM, Jan Beulich wrote: > On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: >> On 11/13/20 4:51 PM, Jan Beulich wrote: >>> On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: On 11/13/20 4:38 PM, Jan Beulich wrote: > On 13.11.2020 15:32, Oleksandr Andrushchenko wrote: >>

Re: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

On 04.12.2020 12:45, Julien Grall wrote: > Hi, > > I haven't looked at the series yet. Just adding some thoughts on why one > would want such option. > > On 04/12/2020 09:43, Jan Beulich wrote: >> On 04.12.2020 09:22, Paul Durrant wrote: From: Jan Beulich Sent: 04 December 2020 07:53

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 07.12.2020 10:11, Oleksandr Andrushchenko wrote: > On 12/7/20 10:48 AM, Jan Beulich wrote: >> On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: >>> On 11/13/20 4:51 PM, Jan Beulich wrote: On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: > On 11/13/20 4:38 PM, Jan Beulich wrote: >>>

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 12/7/20 11:28 AM, Jan Beulich wrote: > On 07.12.2020 10:11, Oleksandr Andrushchenko wrote: >> On 12/7/20 10:48 AM, Jan Beulich wrote: >>> On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: On 11/13/20 4:51 PM, Jan Beulich wrote: > On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: >>

Re: [PATCH v3 1/2] x86/IRQ: make max number of guests for a shared IRQ configurable

On 06.12.2020 18:43, Igor Druzhinin wrote: > ... and increase the default to 16. > > Current limit of 7 is too restrictive for modern systems where one GSI > could be shared by potentially many PCI INTx sources where each of them > corresponds to a device passed through to its own guest. Some syst

Re: [PATCH v3 2/2] x86/IRQ: allocate guest array of max size only for shareable IRQs

On 06.12.2020 18:43, Igor Druzhinin wrote: > ... and increase default "irq-max-guests" to 32. > > It's not necessary to have an array of a size more than 1 for non-shareable > IRQs and it might impact scalability in case of high "irq-max-guests" > values being used - every IRQ in the system includ

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 07.12.2020 10:37, Oleksandr Andrushchenko wrote: > On 12/7/20 11:28 AM, Jan Beulich wrote: >> On 07.12.2020 10:11, Oleksandr Andrushchenko wrote: >>> On 12/7/20 10:48 AM, Jan Beulich wrote: On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: > So, I started looking at the bus2bridge and

[libvirt test] 157251: regressions - FAIL

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

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 04.12.2020 16:52, Dario Faggioli wrote: > On Tue, 2020-12-01 at 09:21 +0100, Juergen Gross wrote: >> The cpupool id is an unsigned value in the public interface header, >> so >> there is no reason why it is a signed value in struct cpupool. >> >> Switch it to unsigned int. >> > I think we can ad

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 01.12.2020 10:01, Jürgen Groß wrote: > On 01.12.20 09:55, Jan Beulich wrote: >> On 01.12.2020 09:21, Juergen Gross wrote: >>> --- a/xen/common/sched/private.h >>> +++ b/xen/common/sched/private.h >>> @@ -505,8 +505,8 @@ static inline void sched_unit_unpause(const struct >>> sched_unit *unit) >>

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 6:46 AM, Thomas Huth wrote: > On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: >> Cross-build s390x target with only KVM accelerator enabled. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> .gitlab-ci.d/crossbuilds-kvm-s390x.yml | 6 ++ >> .gitlab-ci.yml

Re: [PATCH 3/8] gitlab-ci: Add KVM X86 cross-build jobs

On 12/7/20 6:20 AM, Thomas Huth wrote: > On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: >> Cross-build x86 target with only KVM accelerator enabled. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> .gitlab-ci.d/crossbuilds-kvm-x86.yml | 6 ++ >> .gitlab-ci.yml |

Re: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

Hi Jan, On 07/12/2020 09:17, Jan Beulich wrote: On 04.12.2020 12:45, Julien Grall wrote: 1) From the recent security issues (such as XSA-343), a knob to disable FIFO would be quite beneficials for vendors that don't need the feature. Except that this wouldn't have been suitable as a duri

Re: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

On 07/12/2020 10:04, Julien Grall wrote: Hi Jan, On 07/12/2020 09:17, Jan Beulich wrote: On 04.12.2020 12:45, Julien Grall wrote: 1) From the recent security issues (such as XSA-343), a knob to disable FIFO would be quite beneficials for vendors that don't need the feature. Except th

Re: [PATCH v2] x86/vmap: handle superpages in vmap_to_mfn()

On 03.12.2020 12:21, Hongyan Xia wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -5194,6 +5194,60 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v) > } \ > } while ( false ) > > +/* Translate mapped Xen address to MFN. */ > +m

[linux-linus test] 157248: regressions - FAIL

flight 157248 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157248/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qem

Re: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

On 07.12.2020 11:04, Julien Grall wrote: > On 07/12/2020 09:17, Jan Beulich wrote: >> On 04.12.2020 12:45, Julien Grall wrote: >>> You are making the assumption that the customer would have the choice to >>> target a specific versions of Xen. This may be undesirable for a cloud >>> provider as sudd

Re: [PATCH v2 7/8] lib: move bsearch code

On 24.11.2020 17:57, Julien Grall wrote: > On 24/11/2020 00:40, Andrew Cooper wrote: >> On a totally separate point,  I wonder if we'd be better off compiling >> with -fgnu89-inline because I can't see any case we're we'd want the C99 >> inline semantics anywhere in Xen. > > This was one of my poi

Re: [PATCH 0/8] gitlab-ci: Add accelerator-specific Linux jobs

On Sun, Dec 06, 2020 at 07:55:00PM +0100, Philippe Mathieu-Daudé wrote: > Hi, > > I was custom to use Travis-CI for testing KVM builds on s390x/ppc > with the Travis-CI jobs. > > During October Travis-CI became unusable for me (extremely slow, > see [1]). Then my free Travis account got updated t

RE: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

> -Original Message- [snip] > >> I've gone from you saying "You really need a solution that can restore > >> the old VM environment, at least temporarily, for that customer." The > >> "temporarily" to me implies that it is at least an option to tie a > >> certain guest to a certain Xen vers

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: > On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: > > Cross-build s390x target with only KVM accelerator enabled. > > > > Signed-off-by: Philippe Mathieu-Daudé > > --- > > .gitlab-ci.d/crossbuilds-kvm-s390x.yml | 6 ++ > > .gitl

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 11:00 AM, Philippe Mathieu-Daudé wrote: > On 12/7/20 6:46 AM, Thomas Huth wrote: >> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: >>> Cross-build s390x target with only KVM accelerator enabled. >>> >>> Signed-off-by: Philippe Mathieu-Daudé >>> --- >>> .gitlab-ci.d/crossbuilds-kvm-

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 11:25 AM, Daniel P. Berrangé wrote: > On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: >> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: >>> Cross-build s390x target with only KVM accelerator enabled. >>> >>> Signed-off-by: Philippe Mathieu-Daudé >>> --- >>> .gitlab-ci.

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 07/12/2020 11.26, Philippe Mathieu-Daudé wrote: > On 12/7/20 11:00 AM, Philippe Mathieu-Daudé wrote: >> On 12/7/20 6:46 AM, Thomas Huth wrote: >>> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: Cross-build s390x target with only KVM accelerator enabled. Signed-off-by: Philippe

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On Mon, Dec 07, 2020 at 11:26:58AM +0100, Philippe Mathieu-Daudé wrote: > On 12/7/20 11:25 AM, Daniel P. Berrangé wrote: > > On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: > >> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: > >>> Cross-build s390x target with only KVM accelerator

[PATCH 0/5] x86/vPCI: MSI/MSI-X related adjustments

1: tolerate (un)masking a disabled MSI-X entry 2: check address in vpci_msi_update() 3: vPCI/MSI-X: fold clearing of entry->updated 4: vPCI/MSI-X: make use of xzalloc_flex_struct() 5: vPCI/MSI-X: tidy init_msix() Jan

[PATCH 1/5] x86/vPCI: tolerate (un)masking a disabled MSI-X entry

None of the four reasons causing vpci_msix_arch_mask_entry() to get called (there's just a single call site) are impossible or illegal prior to an entry actually having got set up: - the entry may remain masked (in this case, however, a prior masked -> unmasked transition would already not have w

Re: [PATCH v2 7/8] xen/arm: Remove Linux specific code that is not usable in XEN

Hello Julien, > On 4 Dec 2020, at 9:05 am, Julien Grall wrote: > > Hi Rahul, > > On 03/12/2020 14:33, Rahul Singh wrote: >>> On 2 Dec 2020, at 2:45 pm, Julien Grall wrote: - -static struct iommu_device *arm_smmu_probe_device(struct device *dev) -{ >>> >>> Most of the code he

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 11:33 AM, Thomas Huth wrote: > On 07/12/2020 11.26, Philippe Mathieu-Daudé wrote: >> On 12/7/20 11:00 AM, Philippe Mathieu-Daudé wrote: >>> On 12/7/20 6:46 AM, Thomas Huth wrote: On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: > Cross-build s390x target with only KVM accelera

[PATCH 2/5] x86/vPCI: check address in vpci_msi_update()

If the upper address bits don't match the interrupt delivery address space window, entirely different behavior would need to be implemented. Refuse such requests for the time being. Replace adjacent hard tabs while introducing MSI_ADDR_BASE_MASK. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hv

[PATCH 3/5] vPCI/MSI-X: fold clearing of entry->updated

Both call sites clear the flag after a successfull call to update_entry(). This can be simplified by moving the clearing into the function, onto its success path. Signed-off-by: Jan Beulich --- As a result it becomes clear that the return value of the function is of no interest to either of the c

[PATCH 4/5] vPCI/MSI-X: make use of xzalloc_flex_struct()

... instead of effectively open-coding it in a type-unsafe way. Signed-off-by: Jan Beulich --- a/xen/drivers/vpci/msix.c +++ b/xen/drivers/vpci/msix.c @@ -23,8 +23,6 @@ #include #include -#define VMSIX_SIZE(num) offsetof(struct vpci_msix, entries[num]) - #define VMSIX_ADDR_IN_RANGE(addr,

[PATCH 5/5] vPCI/MSI-X: tidy init_msix()

First of all introduce a local variable for the to be allocated struct. The compiler can't CSE all the occurrences (I'm observing 80 bytes of code saved with gcc 10). Additionally, while the caller can cope and there was no memory leak, globally "announce" the struct only once done initializing it.

[PATCH] x86/vIO-APIC: make use of xmalloc_flex_struct()

... instead of effectively open-coding it in a type-unsafe way. Drop hvm_vioapic_size() altogether, folding the other use in a memset() invocation into the subsequent loop. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -622,9 +622,9 @@ void vioap

[PATCH] x86/vPMU: make use of xmalloc_flex_struct()

... instead of effectively open-coding it in a type-unsafe way. Drop the regs_sz variable altogether, replacing other uses suitably. Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/vpmu_amd.c +++ b/xen/arch/x86/cpu/vpmu_amd.c @@ -44,9 +44,6 @@ static const u32 __read_mostly *counters static c

Re: [PATCH v2 7/8] xen/arm: Remove Linux specific code that is not usable in XEN

On 07/12/2020 10:36, Rahul Singh wrote: I would implement it in include/xen/compiler.h. Ok. I will implement and will share the patch for “__attribute__((__fallthrough__)) ” but for SMMUv3 is that ok if we can proceed with “ /* fallthrough */ ". The first approach should always be to work

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

Marek, On 06.12.20 17:47, Jason Andryuk wrote: On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki wrote: On Fri, Dec 04, 2020 at 01:08:03PM +0100, Christoph Hellwig wrote: On Fri, Dec 04, 2020 at 12:08:47PM +0100, Marek

Re: [PATCH] x86/vIO-APIC: make use of xmalloc_flex_struct()

On 07/12/2020 10:49, Jan Beulich wrote: > ... instead of effectively open-coding it in a type-unsafe way. Drop > hvm_vioapic_size() altogether, folding the other use in a memset() > invocation into the subsequent loop. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [PATCH] x86/vPMU: make use of xmalloc_flex_struct()

On 07/12/2020 10:50, Jan Beulich wrote: > ... instead of effectively open-coding it in a type-unsafe way. Drop the > regs_sz variable altogether, replacing other uses suitably. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [PATCH V3 01/23] x86/ioreq: Prepare IOREQ feature for making it common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -17,15 +17,15 @@ > */ > > #include > +#include > +#include > #include > +#include > #include > -#include > +#include > #include > -#include > #include > -#incl

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 11:34 AM, Daniel P. Berrangé wrote: > On Mon, Dec 07, 2020 at 11:26:58AM +0100, Philippe Mathieu-Daudé wrote: >> On 12/7/20 11:25 AM, Daniel P. Berrangé wrote: >>> On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote: > C

Re: [PATCH V3 02/23] x86/ioreq: Add IOREQ_STATUS_* #define-s and update code for moving

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/include/asm-x86/hvm/ioreq.h > +++ b/xen/include/asm-x86/hvm/ioreq.h > @@ -74,6 +74,10 @@ unsigned int hvm_broadcast_ioreq(ioreq_t *p, bool > buffered); > > void hvm_ioreq_init(struct domain *d); > > +#define IOREQ_STATUS_HANDLED

[PATCH v2 0/5] gitlab-ci: Add accelerator-specific Linux jobs

Since v1: - Documented cross_accel_build_job template (Claudio) - Only add new job for s390x (Thomas) - Do not add entry to MAINTAINERS (Daniel) - Document 'build-tcg-disabled' job is X86 + KVM - Drop the patches with negative review feedbacks Hi, I was custom to use Travis-CI for testing KVM bui

[PATCH v2 1/5] gitlab-ci: Document 'build-tcg-disabled' is a KVM X86 job

Document what this job cover (build X86 targets with KVM being the single accelerator available). Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d0173e82b16..ee31b1020fe 100644 --- a/.gitlab-

[PATCH v2 2/5] gitlab-ci: Replace YAML anchors by extends (cross_system_build_job)

'extends' is an alternative to using YAML anchors and is a little more flexible and readable. See: https://docs.gitlab.com/ee/ci/yaml/#extends More importantly it allows exploding YAML jobs. Reviewed-by: Wainer dos Santos Moschetta Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé

[PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

Introduce a job template to cross-build accelerator specific jobs (enable a specific accelerator, disabling the others). The specific accelerator is selected by the $ACCEL environment variable (default to KVM). Extra options such disabling other accelerators are passed via the $ACCEL_CONFIGURE_OP

[PATCH v2 4/5] gitlab-ci: Add KVM s390x cross-build jobs

Cross-build s390x target with only KVM accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index d8685ade376..7a94a66b4b3

[PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

Cross-build ARM and X86 targets with only Xen accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 15 +++ 1 file changed, 15 insertions(+) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 7a94a66b4b3..31f10f1e14

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 12:14 PM, Philippe Mathieu-Daudé wrote: > On 12/7/20 11:34 AM, Daniel P. Berrangé wrote: >> On Mon, Dec 07, 2020 at 11:26:58AM +0100, Philippe Mathieu-Daudé wrote: >>> On 12/7/20 11:25 AM, Daniel P. Berrangé wrote: On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: > O

Re: [PATCH V3 03/23] x86/ioreq: Provide out-of-line wrapper for the handle_mmio()

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -36,6 +36,11 @@ > #include > #include > > +bool ioreq_complete_mmio(void) > +{ > +return handle_mmio(); > +} As indicated before I don't like out-of-line functions like

Re: [PATCH v3 1/2] x86/IRQ: make max number of guests for a shared IRQ configurable

On 07/12/2020 09:43, Jan Beulich wrote: > On 06.12.2020 18:43, Igor Druzhinin wrote: >> @@ -1633,11 +1640,12 @@ int pirq_guest_bind(struct vcpu *v, struct pirq >> *pirq, int will_share) >> goto retry; >> } >> >> -if ( action->nr_guests == IRQ_MAX_GUESTS ) >> +if ( action->n

Re: [PATCH v2 1/5] gitlab-ci: Document 'build-tcg-disabled' is a KVM X86 job

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Document what this job cover (build X86 targets with > KVM being the single accelerator available). > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.yml | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/.gitlab-ci.yml

Re: [PATCH V3 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4699,50 +4699,6 @@ int xenmem_add_to_physmap_one( > return rc; > } > > -int arch_acquire_resource(struct domain *d, unsigned int type, > - unsigned int id, uns

Re: [PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Introduce a job template to cross-build accelerator specific > jobs (enable a specific accelerator, disabling the others). > > The specific accelerator is selected by the $ACCEL environment > variable (default to KVM). > > Extra options such di

Re: [PATCH V3 04/23] xen/ioreq: Make x86's IOREQ feature common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/include/asm-x86/hvm/ioreq.h > +++ b/xen/include/asm-x86/hvm/ioreq.h > @@ -19,8 +19,7 @@ > #ifndef __ASM_X86_HVM_IOREQ_H__ > #define __ASM_X86_HVM_IOREQ_H__ > > -#define HANDLE_BUFIOREQ(s) \ > -((s)->bufioreq_handling != HVM_IOREQS

Re: [PATCH v2 4/5] gitlab-ci: Add KVM s390x cross-build jobs

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Cross-build s390x target with only KVM accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/.gitlab-ci.d/crossbuild

Re: [PATCH v3 1/2] x86/IRQ: make max number of guests for a shared IRQ configurable

On 07.12.2020 12:28, Igor Druzhinin wrote: > On 07/12/2020 09:43, Jan Beulich wrote: >> On 06.12.2020 18:43, Igor Druzhinin wrote: >>> @@ -1633,11 +1640,12 @@ int pirq_guest_bind(struct vcpu *v, struct pirq >>> *pirq, int will_share) >>> goto retry; >>> } >>> >>> -if ( action->

Re: [PATCH V3 05/23] xen/ioreq: Make x86's hvm_ioreq_needs_completion() common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/include/xen/ioreq.h > +++ b/xen/include/xen/ioreq.h > @@ -21,6 +21,13 @@ > > #include > > +static inline bool ioreq_needs_completion(const ioreq_t *ioreq) > +{ > +return ioreq->state == STATE_IOREQ_READY && > + !ioreq-

Re: [PATCH V3 06/23] xen/ioreq: Make x86's hvm_mmio_first(last)_byte() common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and these helpers will be used > on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes > with "ioreq". > > Signed-off-by: Oleksandr Tyshchenko > Reviewed-by: Paul Durr

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: > Marek, > > On 06.12.20 17:47, Jason Andryuk wrote: > > On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: > > > > > > On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki > > > wrote: > > > > On Fri, Dec 04, 2020

Re: [PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Cross-build ARM and X86 targets with only Xen accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/.gitlab-ci.d/crossbuil

Re: [PATCH v2] x86/vmap: handle superpages in vmap_to_mfn()

On Mon, 2020-12-07 at 11:11 +0100, Jan Beulich wrote: > On 03.12.2020 12:21, Hongyan Xia wrote: > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -5194,6 +5194,60 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long > > v) > > } \ > > }

Re: [PATCH V3 07/23] xen/ioreq: Make x86's hvm_ioreq_(page/vcpu/server) structs common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and these structs will be used > on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes. > > Signed-off-by: Oleksandr Tyshchenko Applicable parts Acked-by: Jan Beulich

Re: [PATCH v2] x86/vmap: handle superpages in vmap_to_mfn()

On 07.12.2020 12:54, Hongyan Xia wrote: > On Mon, 2020-12-07 at 11:11 +0100, Jan Beulich wrote: >> On 03.12.2020 12:21, Hongyan Xia wrote: >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -5194,6 +5194,60 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long >>> v) >>> }

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On 07.12.20 12:48, Marek Marczykowski-Górecki wrote: On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: Marek, On 06.12.20 17:47, Jason Andryuk wrote: On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki wrote:

Re: [PATCH V3 08/23] xen/ioreq: Move x86's ioreq_server to struct domain

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and this struct will be used > on Arm as is. Move it to common struct domain. This also > significantly reduces the layering violation in the common code > (*arch.hvm* usage). > >

Re: [PATCH V3 09/23] xen/dm: Make x86's DM feature common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Julien Grall > > As a lot of x86 code can be re-used on Arm later on, this patch > splits devicemodel support into common and arch specific parts. > > The common DM feature is supposed to be built with IOREQ_SERVER > option enabled (as wel

Re: [PATCH V3 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

On 07.12.2020 12:35, Jan Beulich wrote: > On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -4699,50 +4699,6 @@ int xenmem_add_to_physmap_one( >> return rc; >> } >> >> -int arch_acquire_resource(struct domain *d, unsigned int type,

RE: [PATCH V3 08/23] xen/ioreq: Move x86's ioreq_server to struct domain

> -Original Message- > From: Jan Beulich > Sent: 07 December 2020 12:05 > To: Oleksandr Tyshchenko ; Paul Durrant > Cc: Oleksandr Tyshchenko ; Andrew Cooper > ; > George Dunlap ; Ian Jackson ; > Julien Grall > ; Stefano Stabellini ; Wei Liu > ; Roger Pau Monné > ; Julien Grall ; > xen

Re: [PATCH v2 8/8] xen/arm: Add support for SMMUv3 driver

Hello Julien, > On 2 Dec 2020, at 4:22 pm, Julien Grall wrote: > > Hi Rahul, > > On 26/11/2020 17:02, Rahul Singh wrote: >> Add support for ARM architected SMMUv3 implementation. It is based on >> the Linux SMMUv3 driver. >> Major differences with regard to Linux driver are as follows: >> 1. On

Re: [PATCH V3 11/23] xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -142,8 +142,8 @@ void hvmemul_cancel(struct vcpu *v) > { > struct hvm_vcpu_io *vio = &v->arch.hvm.hvm_io; > > -vio->io_req.state = STATE_IOREQ_NONE; > -vio->io

Re: [PATCH V3 12/23] xen/ioreq: Remove "hvm" prefixes from involved function names

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > @@ -301,8 +301,8 @@ bool is_ioreq_server_page(struct domain *d, const struct > page_info *page) > return found; > } > > -static void hvm_update_ioreq_evtchn(struct ioreq_server *s, > -struct ioreq_vcpu *

Re: [PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

On 12/7/20 12:51 PM, Thomas Huth wrote: > On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: >> Cross-build ARM and X86 targets with only Xen accelerator enabled. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> .gitlab-ci.d/crossbuilds.yml | 15 +++ >> 1 file changed, 15 inserti

[ovmf test] 157255: all pass - PUSHED

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

[PATCH v3] x86/vmap: handle superpages in vmap_to_mfn()

From: Hongyan Xia There is simply no guarantee that vmap won't return superpages to the caller. It can happen if the list of MFNs are contiguous, or we simply have a large granularity. Although rare, if such things do happen, we will simply hit BUG_ON() and crash. Introduce xen_map_to_mfn() to t

Re: [PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

On 12/7/20 12:37 PM, Thomas Huth wrote: > On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: >> Introduce a job template to cross-build accelerator specific >> jobs (enable a specific accelerator, disabling the others). >> >> The specific accelerator is selected by the $ACCEL environment >> variabl

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On Mon, Dec 07, 2020 at 01:00:14PM +0100, Jürgen Groß wrote: > On 07.12.20 12:48, Marek Marczykowski-Górecki wrote: > > On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: > > > Marek, > > > > > > On 06.12.20 17:47, Jason Andryuk wrote: > > > > On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Mon

RE: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm

Hi Oleksandr, I have tested v3. It works well with the latest virtio-backend service[1]. [1] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml1 Tested-by: Wei Chen Regards, Wei Chen > -Original Message- > From: Oleksandr > Sent: 2020年11月30日 19:23 > To: xen-devel@lists.xenproj

[xen-unstable test] 157249: tolerable FAIL

flight 157249 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/157249/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 157233 Tests which did not succ

Re: [PATCH v3] x86/vmap: handle superpages in vmap_to_mfn()

On 07.12.2020 13:49, Hongyan Xia wrote: > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -175,6 +175,7 @@ bool scrub_free_pages(void); > } while ( false ) > #define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0) > > +mfn_t xen_map_to_mfn(unsigned long va); > /* Map machine page ra

[PATCH v3 0/5] gitlab-ci: Add accelerator-specific Linux jobs

Since v2: - Fixed ARM Xen job - Renamed jobs with -$accel trailer (Thomas) Since v1: - Documented cross_accel_build_job template (Claudio) - Only add new job for s390x (Thomas) - Do not add entry to MAINTAINERS (Daniel) - Document 'build-tcg-disabled' job is X86 + KVM - Drop the patches with negat

[PATCH v3 1/5] gitlab-ci: Document 'build-tcg-disabled' is a KVM X86 job

Document what this job cover (build X86 targets with KVM being the single accelerator available). Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d0173e82b16..ee31b10

[PATCH v3 2/5] gitlab-ci: Replace YAML anchors by extends (cross_system_build_job)

'extends' is an alternative to using YAML anchors and is a little more flexible and readable. See: https://docs.gitlab.com/ee/ci/yaml/#extends More importantly it allows exploding YAML jobs. Reviewed-by: Wainer dos Santos Moschetta Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé

[PATCH v3 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

Introduce a job template to cross-build accelerator specific jobs (enable a specific accelerator, disabling the others). The specific accelerator is selected by the $ACCEL environment variable (default to KVM). Extra options such disabling other accelerators are passed via the $ACCEL_CONFIGURE_OP

[PATCH v3 4/5] gitlab-ci: Add KVM s390x cross-build jobs

Cross-build s390x target with only KVM accelerator enabled. Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index

[PATCH v3 5/5] gitlab-ci: Add Xen cross-build jobs

Cross-build ARM and X86 targets with only Xen accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 51896bbc9fb..bd6473a75a7

[PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory

Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen backend private page caches. Fix that by using page->zone_device_data instead. Fixes: 9e2369c06c8

[PATCH 0/2] xen: fix using ZONE_DEVICE memory for foreign mappings

Fix an issue found in dom0 when running on a host with NVMe. Juergen Gross (2): xen: add helpers for caching grant mapping pages xen: don't use page->lru for ZONE_DEVICE memory drivers/block/xen-blkback/blkback.c | 89 drivers/block/xen-blkback/common.h | 4 +- drive

[PATCH 1/2] xen: add helpers for caching grant mapping pages

Instead of having similar helpers in multiple backend drivers use common helpers for caching pages allocated via gnttab_alloc_pages(). Make use of those helpers in blkback and scsiback. Signed-off-by: Juergen Gross --- drivers/block/xen-blkback/blkback.c | 89 ++--- driv

[Help Wanted] New toolstack Rust PoC

Hi all, As you may know: we are working on a rust PoC (https://github.com/xcp-ng/xenopsd-ng/rust/ ) for the new Xen Toolstack. We have partial bindings for Xenctrl and Xenstore and with that we're able to pause/unpause/shutdown a guest and we're c

Re: [Help Wanted] New toolstack Rust PoC

Same mail as plain text, sorry for the incovenience and the none readability of my previous one. Hi all, As you may know: we are working on a rust PoC (https://github.com/xcp-ng/xenopsd-ng/rust/ ) for the new Xen Toolstack. We have partial bindi

Re: [PATCH v3 5/5] gitlab-ci: Add Xen cross-build jobs

On 07/12/2020 14.15, Philippe Mathieu-Daudé wrote: > Cross-build ARM and X86 targets with only Xen accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/.gitlab-ci.d/crossbuild

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 07.12.20 10:59, Jan Beulich wrote: On 01.12.2020 10:01, Jürgen Groß wrote: On 01.12.20 09:55, Jan Beulich wrote: On 01.12.2020 09:21, Juergen Gross wrote: --- a/xen/common/sched/private.h +++ b/xen/common/sched/private.h @@ -505,8 +505,8 @@ static inline void sched_unit_unpause(const struct

  1   2   >