Re: [Xen-devel] broken build: 448c03b3cbe14873ee637755a29ea26ee7ca9ef9

On 19/03/18 20:04, Doug Goldstein wrote: > commit 448c03b3cbe14873ee637755a29ea26ee7ca9ef9 > Author: Juergen Gross > Date: Mon Feb 26 09:46:12 2018 +0100 > > This commit breaks the build of qemu-xen-traditional for: > > Ubuntu 14.04:

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

flight 120916 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/120916/ 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] [PATCH v1 01/15] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

Hi Manish, On 03/16/2018 11:58 AM, Manish Jaggi wrote: Add MIDR values for Cavium ThunderX1 SoC family. Did you intend to use a : instead of .? ThunderX1, 81XX, 83XX. Signed-off-by: Manish Jaggi diff --git a/xen/include/asm-arm/processor.h

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

>>> On 19.03.18 at 17:57, wrote: >> -Original Message- > [snip] >> >> How are you making sure this is a mapping that was established via >> >> the map op? Without that this can be (ab)used to ... >> >> >> >> > +put_page(page); >> >> >> >> ... underflow the

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

On 03/16/2018 11:58 AM, Manish Jaggi wrote: This patchset is a Xen port of Marc's patchset. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] The current RFC patchset is a subset of [1], as it handleing only Group1 traps as a PoC. Most of the trap code is added in vsysreg.c. Trap handler

Re: [Xen-devel] [PATCH v1 03/15] arm: Placeholder for handling Group0/1 traps for Cavium Erratum 30115

Hi Manish, On 03/16/2018 11:58 AM, Manish Jaggi wrote: Since this is a SoC errata and trapping of certain group1 registers should not affect the normal flow. A new file vgic-v3-sr.c is added. You trap both group1 and group0. But your first sentence is a bit difficult to understand. How

Re: [Xen-devel] [PATCH] x86/xen: Delay get_cpu_cap until stack canary is established

On 19/03/18 23:22, Boris Ostrovsky wrote: > On 03/19/2018 12:58 PM, Jason Andryuk wrote: >> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a >> call to get_cpu_cap, which is fstack-protected. This is works on x86-64 > > s/This is works/This works/ > > Reviewed-by: Boris

Re: [Xen-devel] [PATCH v1 02/15] arm64: Add config for Cavium Thunder erratum 30115

Hi, On 03/16/2018 11:58 AM, Manish Jaggi wrote: Some Cavium Thunder CPUs suffer a problem where a Xen guest may inadvertently cause the host kernel to quit receiving interrupts. This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will provide workaround. Signed-off-by: Manish Jaggi

Re: [Xen-devel] [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

On 03/20/2018 01:23 AM, Boris Ostrovsky wrote: On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello! Resending with all the patches squashed on Daniel's request. Which of the two series are we supposed to review? The

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

On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote: > On Mon, 19 Mar 2018 15:58:02 + > Roger Pau Monné wrote: > > >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko wrote: > >> Much like normal PCI BARs or other chipset-specific memory-mapped > >>

[Xen-devel] TLB flushing

While hunting a strange bug in my PCID patch series hinting at some TLB invalidation problem I discovered a piece of code looking rather fishy to me. Is it correct for new_tlbflush_clock_period() to use FLUSH_TLB instead of FLUSH_TLB_GLOBAL? While not being a problem in current code as both will

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Tue, Mar 20, 2018 at 07:20:53AM +1000, Alexey G wrote: > On Mon, 19 Mar 2018 17:49:09 + > Roger Pau Monné wrote: > > >On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote: > >> This patch extends hvmloader_acpi_build_tables() with code which > >>

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote: > On Mon, 19 Mar 2018 17:33:34 + > Roger Pau Monné wrote: > > >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko wrote: > >> This adds construct_mcfg() function to libacpi which allows to build > >>

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2018 08:12 > To: Paul Durrant > Cc: Andrew Cooper ; George Dunlap > ; Ian Jackson ; Wei Liu >

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins wrote: > On 03/15/2018 03:45 PM, Boris Ostrovsky wrote: >> On 03/15/2018 10:22 AM, Joao Martins wrote: >>> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and >>> changing only the acpi_id. For processors

Re: [Xen-devel] [PATCH v2 02/45] ARM: Implement vcpu_kick()

>>> On 15.03.18 at 21:30, wrote: > If we change something in a vCPU that affects its runnability or > otherwise needs the vCPU's attention, we might need to tell the scheduler > about it. > We are using this in one place (vIRQ injection) at the moment, but will > need

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/20/2018 09:41 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins > wrote: >> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote: >>> On 03/15/2018 10:22 AM, Joao Martins wrote: All uploaded PM data from non-dom0 CPUs takes the info from

Re: [Xen-devel] [PATCH v10 07/11] vpci/bars: add handlers to map the BARs

On Mon, Mar 19, 2018 at 10:18:34AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 14:30, wrote: > > +static int modify_bars(const struct pci_dev *pdev, bool map, bool rom_only) > > +{ > > +struct vpci_header *header = >vpci->header; > > +struct rangeset *mem =

Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

On Tue, Mar 20, 2018 at 05:03:09AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 14:30, wrote: > > +int vpci_msix_arch_print(const struct vpci_msix *msix) > > +{ > > +unsigned int i; > > + > > +for ( i = 0; i < msix->max_entries; i++ ) > > +{ > > +const

Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

On Tue, Mar 20, 2018 at 11:43:00AM +, Roger Pau Monné wrote: > On Tue, Mar 20, 2018 at 05:03:09AM -0600, Jan Beulich wrote: > > >>> On 16.03.18 at 14:30, wrote: > > > +printk(XENLOG_G_WARNING > > > + "Failed to remove MSIX table [%" PRI_gfn

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

On 03/19/2018 05:28 PM, Daniel Vetter wrote: On Mon, Mar 19, 2018 at 3:19 PM, Oleksandr Andrushchenko wrote: On 03/19/2018 03:51 PM, Daniel Vetter wrote: On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote: Hi, Daniel! Sorry, if I strip the patch too

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote: > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > > QEMU coding style at the moment asks for all non-system > > include files to be used with #include "foo.h". > > However this rule actually does not make sense and > > creates

Re: [Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

Dear All, Any comments for the patch? It addressed the issue mentioned here: https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00452.html -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote: > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote: > > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > > > > QEMU coding style at the

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote: > QEMU coding style at the moment asks for all non-system > include files to be used with #include "foo.h". > However this rule actually does not make sense and > creates issues for when the included file is generated. > > In C,

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 10:27:19AM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote: > > On 20 March 2018 at 09:44, Daniel P. Berrangé wrote: > > > We can follow what autoconf does, and add a check to configure to see if > > >

Re: [Xen-devel] [PATCH 1/3] x86/pv: Avoid locked bit manipulation in register_guest_callback()

On Thu, Mar 15, 2018 at 11:58:40AM +, Andrew Cooper wrote: > Changes to arch.vgc_flags are made to current in syncrhonous context only, and > don't need to be locked. (The only other changes are via > arch_set_info_guest(), which operates on descheduled vcpus only). > > Replace the

Re: [Xen-devel] [Qemu-block] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote: > QEMU coding style at the moment asks for all non-system > include files to be used with #include "foo.h". > However this rule actually does not make sense and > creates issues for when the included file is generated. > > In C,

Re: [Xen-devel] broken build: 448c03b3cbe14873ee637755a29ea26ee7ca9ef9

On 3/20/18 1:07 AM, Juergen Gross wrote: > On 19/03/18 20:04, Doug Goldstein wrote: >> commit 448c03b3cbe14873ee637755a29ea26ee7ca9ef9 >> Author: Juergen Gross >> Date: Mon Feb 26 09:46:12 2018 +0100 >> >> This commit breaks the build of qemu-xen-traditional for: >> >> Ubuntu

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote: > Hi, > > > > So for these, we should use "". None of these are generated files though. > > > > That leads to crazy inconsistent message for developers where 50% of QEMU > > header files must use <> and the other 50% of header

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

flight 120946 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/120946/ 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] xsm:schedop: introduce vcpuinfo permissions verification

On Thu, 2018-02-15 at 12:51 +0200, Andrii Anisov wrote: > From: Andrii Anisov > > Introduce per-vcpu scheduler operations permission verification. > As long as Xvcpuinfo are in fact scheduler configuration > manipulations > there is no need to introduce specific access

Re: [Xen-devel] [PATCH 3/3] x86/pv: Minor tweaks to {, compat_}register_guest_callback()

On Thu, Mar 15, 2018 at 11:58:42AM +, Andrew Cooper wrote: > * Being internal functions, use int rather than long for the return value > * Factor out pv_vcpu into a local variable. Reduces code volume, and removes >some split lines. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

On Tue, 2018-03-20 at 14:19 +0200, Andrii Anisov wrote: > Dear All, > > Any comments for the patch? > > It addressed the issue mentioned here: > https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00452 > .html > Oops, sorry, I had missed it. Now I've replied. I think it still

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 12:39:00PM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote: > > On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote: > > > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote: > > > > On

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

flight 120987 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120987/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

Re: [Xen-devel] [Qemu-block] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 01:10:41PM +, Stefan Hajnoczi wrote: > On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote: > > QEMU coding style at the moment asks for all non-system > > include files to be used with #include "foo.h". > > However this rule actually does not make sense

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote: > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > > > QEMU coding style at the moment asks for all non-system > > > include files to be used with #include

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote: > > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote: > > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote: > > > > Le

Re: [Xen-devel] [PATCH 2/3] x86/pv: Fold {compat_}unregister_guest_callback() into its non-compat counterpart

On Thu, Mar 15, 2018 at 11:58:41AM +, Andrew Cooper wrote: > These functions are almost identical. They differ only in the error emitted > for the use of CALLBACKTYPE_syscall (which is inconsequential to guests), and > the type of their argument. > > Have the callers pass the unreg.type

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote: > > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote: > > > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote: > > > > On

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

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

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/20/2018 05:41 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins > wrote: >> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote: >>> On 03/15/2018 10:22 AM, Joao Martins wrote: All uploaded PM data from non-dom0 CPUs takes the info from

[Xen-devel] Spectre Mitigations in Xen 4.6

Hi, I've been experimenting with Linux 4.14 on Xen 4.6. Now that Intel microcode is generally available, I'm starting to exercise the new mitigation code paths. For Xen 4.6-4.8, microcode loading happens after init_speculation_mitigations, so Xen only detects the boot firmware features. The

Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

>>> On 20.03.18 at 12:43, wrote: > Since you only had comments on patch 7 and 11 and there's the extra > fix for the test harness, should I just send those and provide you > with a git branch that contains the rest? Well, if it's not too much hassle for you I'd prefer if

Re: [Xen-devel] [PATCH v5 03/16] xen/arm: mm: Use gaddr_to_gfn rather than _gfn(paddr_to_pfn(...))

Hi George, On 03/15/2018 04:15 PM, George Dunlap wrote: On Wed, Mar 14, 2018 at 6:19 PM, wrote: From: Julien Grall The construction _gfn(paddr_to_pfn(...)) can be simplified by using gaddr_to_gfn. Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > QEMU coding style at the moment asks for all non-system > include files to be used with #include "foo.h". > However this rule actually does not make sense and > creates issues for when the included file is generated. If you change that, we can

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

>>> On 19.03.18 at 22:20, wrote: > On Mon, 19 Mar 2018 17:49:09 + > Roger Pau Monné wrote: >>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote: >>> --- a/tools/firmware/hvmloader/util.c >>> +++ b/tools/firmware/hvmloader/util.c >>> @@

Re: [Xen-devel] TLB flushing

>>> On 20.03.18 at 10:29, wrote: > On 20/03/18 10:19, Jan Beulich wrote: > On 20.03.18 at 09:50, wrote: >>> While hunting a strange bug in my PCID patch series hinting at some >>> TLB invalidation problem I discovered a piece of code looking rather >>> fishy

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote: > On 20 March 2018 at 09:44, Daniel P. Berrangé wrote: > > We can follow what autoconf does, and add a check to configure to see if > > there are generated files left in the source dir, when configuring with > >

Re: [Xen-devel] [PATCH v2 00/45] New VGIC(-v2) implementation

Hi, On 20/03/18 08:30, Julien Grall wrote: > Hi, > > On 03/15/2018 08:30 PM, Andre Przywara wrote: >> tl;dr: Coarse changelog below, individual patches have changelogs as >> well. git branch: >> http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v2 >> >>

Re: [Xen-devel] [PATCH v5 04/16] xen/arm: mm: Remove unused M2P code

On 03/15/2018 07:20 AM, Alan Robinson wrote: Hi Julien, Hi Alan, At the same time move the remaining M2P define just above just above set_gpfn_from_mfn to keep all the dummy helpers for M2P together. At the same time move the remaining M2P define just above set_gpfn_from_mfn to keep

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote: > On Mon, 19 Mar 2018 17:01:18 + > Roger Pau Monné wrote: > > >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote: > >> Provide a new domain config option to select the emulated machine > >> type,

Re: [Xen-devel] [PATCH 3/3] x86/pv: Minor tweaks to {, compat_}register_guest_callback()

>>> On 15.03.18 at 12:58, wrote: > --- a/xen/arch/x86/pv/callback.c > +++ b/xen/arch/x86/pv/callback.c > @@ -71,10 +71,11 @@ static void unregister_guest_nmi_callback(void) > memset(t, 0, sizeof(*t)); > } > > -static long register_guest_callback(struct

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

flight 120943 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/120943/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120037

Re: [Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

Hi, Sorry for the formatting. On 20 Mar 2018 19:01, "Andre Przywara" wrote: I am happy to add a comment saying that a list is not the right data structure. Fair enough. I won't argue more, let's keep the list and add a comment. I do want to see that series merged

Re: [Xen-devel] [PATCH v10 07/11] vpci/bars: add handlers to map the BARs

>>> On 20.03.18 at 12:12, wrote: > On Mon, Mar 19, 2018 at 10:18:34AM -0600, Jan Beulich wrote: >> >>> On 16.03.18 at 14:30, wrote: >> > +static int modify_bars(const struct pci_dev *pdev, bool map, bool >> > rom_only) >> > +{ >> > +struct

Re: [Xen-devel] [PATCH v2 00/45] New VGIC(-v2) implementation

Hi, On 03/15/2018 08:30 PM, Andre Przywara wrote: tl;dr: Coarse changelog below, individual patches have changelogs as well. git branch: http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v2 git://linux-arm.org/xen-ap.git branch vgic-new/v2 Another update, addressing

Re: [Xen-devel] [PATCH 05/20] arm/boot: Mark construct_dom0() as __init

On 03/20/2018 03:40 AM, Julien Grall wrote: Hi Andrew, On 03/19/2018 07:13 PM, Andrew Cooper wrote: Its sole caller, start_xen(), is __init. Actually, most of that files could benefits of __init as this is domain only build. In any case, this patch is already a good start. So:

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

> -Original Message- > From: Roger Pau Monne > Sent: 20 March 2018 08:51 > To: Alexey G > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Ian Jackson ; Jan > Beulich ; Wei Liu

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote: > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > > QEMU coding style at the moment asks for all non-system > > include files to be used with #include "foo.h". > > However this rule actually does not make sense and > > creates

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

>>> On 20.03.18 at 10:32, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2018 08:12 >> >> >>> On 19.03.18 at 17:57, wrote: >> > What I meant was that safety (against underflow) is predicated on >> > iommu_lookup_page()

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

So, how do we address the performance regression fixed by this patch? Olaf Am Mon, 12 Mar 2018 10:15:08 +0100 schrieb Olaf Hering : > Am Tue, 6 Mar 2018 11:07:54 + > schrieb Andrew Cooper : > > > > Add a new domctl

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On 20 March 2018 at 09:44, Daniel P. Berrangé wrote: > We can follow what autoconf does, and add a check to configure to see if > there are generated files left in the source dir, when configuring with > builddir != srcdir, and exit with error, telling user to clean their >

Re: [Xen-devel] [PATCH] x86/vtx: Introduce a typed union for CR access exit information

>>> On 15.03.18 at 13:07, wrote: > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -2448,27 +2448,24 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, > break; > case EXIT_REASON_CR_ACCESS: > { > -unsigned

Re: [Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

Hi, On 19/03/18 21:53, Julien Grall wrote: > > > On 03/19/2018 05:32 PM, Andre Przywara wrote: >> Hi, > > Hi, > >> On 06/03/18 18:13, Julien Grall wrote: >>> Hi Andre, >>> >>> On 05/03/18 16:03, Andre Przywara wrote: The new VGIC implementation centers around a struct vgic_irq instance

Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

>>> On 16.03.18 at 14:30, wrote: > +int vpci_msix_arch_print(const struct vpci_msix *msix) > +{ > +unsigned int i; > + > +for ( i = 0; i < msix->max_entries; i++ ) > +{ > +const struct vpci_msix_entry *entry = >entries[i]; > + > +printk("%6u

Re: [Xen-devel] [PATCH v5 04/16] xen/arm: mm: Remove unused M2P code

Hi George, On 03/15/2018 04:25 PM, George Dunlap wrote: On Wed, Mar 14, 2018 at 6:19 PM, wrote: From: Julien Grall Arm does not have an M2P and very unlikely to get one in the future, therefore don't keep defines that are not necessary in the

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

On Tue, Mar 20, 2018 at 09:44:33AM +1000, Alexey G wrote: > On Mon, 19 Mar 2018 15:30:14 + > Roger Pau Monné wrote: > > >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko wrote: > >> +{ > >> +case 0x0300: > > > >All this values need to be defines

Re: [Xen-devel] TLB flushing

>>> On 20.03.18 at 09:50, wrote: > While hunting a strange bug in my PCID patch series hinting at some > TLB invalidation problem I discovered a piece of code looking rather > fishy to me. > > Is it correct for new_tlbflush_clock_period() to use FLUSH_TLB instead > of

Re: [Xen-devel] TLB flushing

On 20/03/18 10:19, Jan Beulich wrote: On 20.03.18 at 09:50, wrote: >> While hunting a strange bug in my PCID patch series hinting at some >> TLB invalidation problem I discovered a piece of code looking rather >> fishy to me. >> >> Is it correct for

[Xen-devel] [PATCH v2] 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 1/3] x86/alternatives: fully leverage automatic NOP filling

>>> On 15.03.18 at 13:43, wrote: > On 14/03/18 08:29, Jan Beulich wrote: >> As of commit 4008c71d7a ("x86/alt: Support for automatic padding >> calculations") there's no point having explict ASM_NOPn instances in >> alternatives anymore - drop them. As a result also

Re: [Xen-devel] [PATCH 11/20] xen/domctl: Merge set_gnttab_limits into createdomain

On 19/03/2018 21:43, Christian Lindig wrote: > >> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: >> >> +max_grant_frames: int32; >> +max_maptrack_frames: int32; > As part of: > >> +type domctl_create_config = >> +{ >> + ssidref: int32; >> + handle:

Re: [Xen-devel] [PATCH v10 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

>>> On 16.03.18 at 14:29, wrote: > This functionality is going to reside in vpci.c (and the corresponding > vpci.h header), and should be arch-agnostic. The handlers introduced > in this patch setup the basic functionality required in order to trap > accesses to the PCI

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote: > On 03/19/2018 05:28 PM, Daniel Vetter wrote: > > There should be no difference between immediate removal and delayed > > removal of the drm_device from the xenbus pov. The lifetimes of the > > front-end (drm_device) and

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 02:46:46PM +0100, Thomas Huth wrote: > On 20.03.2018 14:32, Gerd Hoffmann wrote: > > Hi, > > > >>> So for these, we should use "". None of these are generated files though. > >> > >> That leads to crazy inconsistent message for developers where 50% of QEMU > >> header

Re: [Xen-devel] Spectre Mitigations in Xen 4.6

>>> On 20.03.18 at 13:58, wrote: > I've been experimenting with Linux 4.14 on Xen 4.6. Now that Intel > microcode is generally > available, I'm starting to exercise the new mitigation code paths. > > For Xen 4.6-4.8, microcode loading happens after >

Re: [Xen-devel] [PATCH] x86/vtx: Introduce a typed union for CR access exit information

>>> On 20.03.18 at 15:28, wrote: > On 20/03/18 10:51, Jan Beulich wrote: > On 15.03.18 at 13:07, wrote: >>> +typedef union cr_access_qual { >>> +unsigned long raw; >>> +struct { >>> +uint16_t cr:4, >>> +

Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

On Tue, Mar 20, 2018 at 07:10:39AM -0600, Jan Beulich wrote: > >>> On 20.03.18 at 12:43, wrote: > > Since you only had comments on patch 7 and 11 and there's the extra > > fix for the test harness, should I just send those and provide you > > with a git branch that contains

Re: [Xen-devel] [PATCH] x86/vtx: Introduce a typed union for CR access exit information

On 20/03/18 10:51, Jan Beulich wrote: On 15.03.18 at 13:07, wrote: >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -2448,27 +2448,24 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs >> *regs, >> break; >> case

Re: [Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

On 02/15/2018 05:51 AM, Andrii Anisov wrote: From: Andrii Anisov Introduce per-vcpu scheduler operations permission verification. As long as Xvcpuinfo are in fact scheduler configuration manipulations there is no need to introduce specific access vectors.

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On 20.03.2018 14:32, Gerd Hoffmann wrote: > Hi, > >>> So for these, we should use "". None of these are generated files though. >> >> That leads to crazy inconsistent message for developers where 50% of QEMU >> header files must use <> and the other 50% of header files must use "". > > The

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On 2018-03-20 14:41, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote: >> Hi, >> So for these, we should use "". None of these are generated files though. >>> >>> That leads to crazy inconsistent message for developers where 50% of QEMU >>> header

Re: [Xen-devel] TLB flushing

On 20/03/18 10:56, Jan Beulich wrote: On 20.03.18 at 10:29, wrote: >> On 20/03/18 10:19, Jan Beulich wrote: >> On 20.03.18 at 09:50, wrote: While hunting a strange bug in my PCID patch series hinting at some TLB invalidation problem I

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 03:50:02PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote: > > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote: > > > Hi, > > > > > > > > So for these, we should use "". None of these are generated

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

flight 120947 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/120947/ 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] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 01:58:32PM +, Daniel P. Berrangé wrote: > > That's the C language for you though. For better or worse, these are > > the rules that K came up with. > > No one seriously tries to keep compliance with original K C these days, > things have moved on massively since then.

[Xen-devel] [PATCH v11 11/12] vpci/msix: add MSI-X handlers

Add handlers for accesses to the MSI-X message control field on the PCI configuration space, and traps for accesses to the memory region that contains the MSI-X table and PBA. This traps detect attempts from the guest to configure MSI-X interrupts and properly sets them up. Note that accesses to

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

On 20/03/18 09:40, Alexandru Isaila 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. > > Chapter 2: SVM

Re: [Xen-devel] [PATCH v2 45/45] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Hi, On 20/03/18 03:13, Julien Grall wrote: > Hi Andre, > > On 03/15/2018 08:30 PM, Andre Przywara wrote: >> diff --git a/xen/arch/arm/vgic/Makefile b/xen/arch/arm/vgic/Makefile >> new file mode 100644 >> index 00..806826948e >> --- /dev/null >> +++ b/xen/arch/arm/vgic/Makefile >> @@ -0,0

[Xen-devel] [PATCH v11 00/12] vpci: PCI config space emulation

Hello, The following series contain an implementation of handlers for the PCI configuration space inside of Xen. This allows Xen to detect accesses to the PCI configuration space and react accordingly. Why is this needed? IMHO, there are two main points of doing all this emulation inside of Xen,

[Xen-devel] [PATCH v11 09/12] vpci/msi: add MSI handlers

Add handlers for the MSI control, address, data and mask fields in order to detect accesses to them and setup the interrupts as requested by the guest. Note that the pending register is not trapped, and the guest can freely read/write to it. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v11 05/12] pci: add support to size ROM BARs to pci_size_mem_bar

Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Julien Grall

[Xen-devel] [PATCH v11 07/12] vpci: add header handlers

Introduce a set of handlers that trap accesses to the PCI BARs and the command register, in order to snoop BAR sizing and BAR relocation. The command handler is used to detect changes to bit 2 (response to memory space accesses), and maps/unmaps the BARs of the device into the guest p2m. A

[Xen-devel] [PATCH v11 10/12] vpci: add a priority parameter to the vPCI register initializer

This is needed for MSI-X, since MSI-X will need to be initialized before parsing the BARs, so that the header BAR handlers are aware of the MSI-X related holes and make sure they are not mapped in order for the trap handlers to work properly. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v11 08/12] x86/pt: mask MSI vectors on unbind

When a MSI device with per-vector masking capabilities is detected or added to Xen all the vectors are masked when initializing it. This implies that the first time the interrupt is bound to a domain it's masked. This however only applies to the first time the interrupt is bound because neither

[Xen-devel] [PATCH v11 12/12] vpci: do not expose unneeded functions to the user-space test harness

Some functions in vpci.c (vpci_remove_device and vpci_add_handlers) are not used by the user-space test harness, so guard them with __XEN__ in order to avoid exposing them to the user-space test harness. Requested-by: Jan Beulich Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v1.5 20/20] xen/domain: Allocate d->vcpu[] in arch_domain_create()

On the ARM side, audit config->max_vcpus after the vgic has been initialised, at which point we have a real upper bound to test against. This allows for the removal of the vgic_max_vcpus() juggling to cope with the call from evtchn_init() before the vgic settings are known. For each arch's

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Fri, Mar 16, 2018 at 10:00:54AM -0700, Maran Wilson wrote: > On 3/16/2018 4:11 AM, Roger Pau Monné wrote: > > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote: > > > The start info structure that is defined as part of the x86/HVM direct > > > boot > > > ABI and used for starting

  1   2   3   >