[Xen-devel] PV DRM doesn't work without auto_translated_physmap feature in Dom0

Hello, I’m trying to use vdispl interface from PV OS, it doesn’t work. Configuration details: Xen 4.12.1 Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019 x86_64 Intel(R) Celeron(R) CPU N3050 @ 1.60GHz GenuineIntel GNU/Linux DomU: x86 Plan9, PV displ_be as a backend

Re: [Xen-devel] PV DRM doesn't work without auto_translated_physmap feature in Dom0

On 06.01.20 08:56, Santucco wrote: Hello, I’m trying to use vdispl interface from PV OS, it doesn’t work. Configuration details: Xen 4.12.1 Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019 x86_64 Intel(R) Celeron(R) CPU N3050 @ 1.60GHz GenuineIntel GNU/Linux DomU:

Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced

On 06.01.2020 01:35, Aaron Janse wrote: > On Fri, Jan 3, 2020, at 4:51 AM, Jan Beulich wrote: >> Did you try disabling use of the IOMMU ("iommu=0" on the Xen >> command line)? > > Unfortunately, Qubes requires iommu. Setting "iommu=0" results in a panic: > > ``` > Couldn't enable IOMMU and iomm

Re: [Xen-devel] [PATCH V6 2/4] x86/altp2m: Add hypercall to set a range of sve bits

On 23.12.2019 18:31, Tamas K Lengyel wrote: >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c >> index 4fc919a9c5..de832dcc6d 100644 >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -3070,6 +3070,70 @@ out: >> return rc; >> } >> >> +/* >> + * Set/clear the #

Re: [Xen-devel] [PATCH v3 2/5] x86/hyperv: provide Hyper-V hypercall functions

On 05.01.2020 17:47, Wei Liu wrote: > +static inline uint64_t hv_do_fast_hypercall(uint16_t code, > +uint64_t input1, uint64_t input2) > +{ > +uint64_t status; > +uint64_t control = (uint64_t)code | HV_HYPERCALL_FAST_BIT; Unnecessary (afaict) cas

Re: [Xen-devel] [PATCH v3 4/5] x86/hyperv: retrieve vp_index from Hyper-V

On Sun, 5 Jan 2020 at 16:49, Wei Liu wrote: > > This will be useful when invoking hypercall that targets specific > vcpu(s). > > Signed-off-by: Wei Liu Reviewed-by: Paul Durrant > --- > v2: > 1. Fold into setup_pcpu_arg function > --- > xen/arch/x86/guest/hyperv/hyperv.c | 5 + > xen/incl

Re: [Xen-devel] [PATCH] x86/shim: Short circuit control/hardware checks in PV_SHIM_EXCLUSIVE builds

On 03.01.2020 21:07, Andrew Cooper wrote: > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -963,10 +963,22 @@ void watchdog_domain_destroy(struct domain *d); > *(that is, this would not be suitable for a driver domain) > * - There is never a reason to deny the hardware

Re: [Xen-devel] [PATCH v3 3/5] x86/hyperv: provide percpu hypercall input page

On 05.01.2020 17:47, Wei Liu wrote: > Hyper-V's input / output argument must be 8 bytes aligned an not cross > page boundary. The easiest way to satisfy those requirements is to use > percpu page. I'm not sure "easiest" is really true here. Others could consider adding __aligned() attributes as ea

Re: [Xen-devel] [PATCH v3 4/5] x86/hyperv: retrieve vp_index from Hyper-V

On 05.01.2020 17:48, Wei Liu wrote: > --- a/xen/include/asm-x86/guest/hyperv.h > +++ b/xen/include/asm-x86/guest/hyperv.h > @@ -66,6 +66,7 @@ struct ms_hyperv_info { > extern struct ms_hyperv_info ms_hyperv; > > DECLARE_PER_CPU(void *, hv_pcpu_input_arg); > +DECLARE_PER_CPU(unsigned int, hv_vp_

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

flight 145649 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145649/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861 test-amd64-i386-f

Re: [Xen-devel] [XEN PATCH v2 0/6] xen: Kconfig update with few extra

On Mon, Dec 23, 2019 at 06:44:11PM +0100, Julien Grall wrote: > Hi, > > On 17/12/2019 11:58, Anthony PERARD wrote: > > Patch series available in this git branch: > > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git > > br.build-system-xen-kconfig-v2 > > > > v2: > > nit chang

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: > I have a multi-function PCI device, behind a PCI bridge, that normally > I assign to a single domain. But now it fails with: > > (XEN) [VT-D]d14: :04:00.0 owned by d0!<0>assign :05:00.0 to dom14 > failed (-22) Is this on the 1st a

Re: [Xen-devel] [PATCH] xsm: hide detailed Xen version from unprivileged guests

On 12/19/19 11:15 PM, Andrew Cooper wrote: > On 19/12/2019 11:35, Jan Beulich wrote: > XENVER_changeset > XENVER_commandline > XENVER_build_id > > Return a more customer friendly empty string instead of "" > which would be shown in tools like dmidecode.> I t

Re: [Xen-devel] [PATCH V6 3/4] x86/mm: Pull out the p2m specifics from p2m_init_altp2m_ept

On 24.12.2019 12:15, George Dunlap wrote: > On 12/24/19 10:08 AM, Alexandru Stefan ISAILA wrote: >> >> >> On 24.12.2019 10:01, George Dunlap wrote: >>> On 12/23/19 2:04 PM, Alexandru Stefan ISAILA wrote: >>> >>> Why? >>> >> >> This was a request from Jan. > > Yes, I saw the Requested-by. It still

Re: [Xen-devel] [Minios-devel] Setting up a monthly Xen Project dinner/pub-meeting

Hi, On 11/12/2019 11:00, Lars Kurth wrote: And this time with the correct list. Really despairing with Outlook which keeps adding random old contacts to my address book and puts them in front of frequently used entries (sigh) *From: *Lars Kurth *Date: *Wednesday, 11 December 2019 at 10:31 *T

Re: [Xen-devel] [PATCH v6 07/12] livepatch: Add per-function applied/reverted state tracking marker

On 5. Jan 2020, at 12:36, Andrew Cooper mailto:andrew.coop...@citrix.com>> wrote: On 26/11/2019 10:07, Pawel Wieczorkiewicz wrote: @@ -1274,6 +1297,9 @@ static void livepatch_do_action(void) else break; @@ -1309,6 +1338,9 @@ static void livepatch_do_action(void) els

Re: [Xen-devel] [PATCH v6 07/12] livepatch: Add per-function applied/reverted state tracking marker

On 06/01/2020 12:22, Wieczorkiewicz, Pawel wrote: > > >> On 5. Jan 2020, at 12:36, Andrew Cooper > > wrote: >> >> On 26/11/2019 10:07, Pawel Wieczorkiewicz wrote: >>> @@ -1274,6 +1297,9 @@ static void livepatch_do_action(void) >>> else > >>> break;

Re: [Xen-devel] [PATCH V6 3/4] x86/mm: Pull out the p2m specifics from p2m_init_altp2m_ept

On 06.01.2020 12:55, Alexandru Stefan ISAILA wrote: > On 24.12.2019 12:15, George Dunlap wrote: >> On 12/24/19 10:08 AM, Alexandru Stefan ISAILA wrote: >>> >>> >>> On 24.12.2019 10:01, George Dunlap wrote: On 12/23/19 2:04 PM, Alexandru Stefan ISAILA wrote: Why? >>> >>> This was

Re: [Xen-devel] [PATCH v4 7/7] Added Resolving Disagreement

On 06/01/2020, 07:25, "Jürgen Groß" wrote: >+## Issue: Small functional issues >+ >+The most common area of disagreements which happen in code reviews, are >+differing opinions on whether small functional issues in a patch series have to >+be resolved or not before the cod

[Xen-devel] [PATCH] livepatch: use proper rc variable in livepatch_do_action()

Fix c&p bug in the livepatch_do_action() code of LIVEPATCH_ACTION_REPLACE case. The correct variable handling return code of revert action is other->rc in this case. Coverity-ID: 1457467 Fixes: 6047104c3c ("livepatch: Add per-function applied/reverted state tracking marker") Signed-off-by: Pawel

Re: [Xen-devel] [PATCH v4 7/7] Added Resolving Disagreement

On 06.01.20 13:54, Lars Kurth wrote: On 06/01/2020, 07:25, "Jürgen Groß" wrote: >+## Issue: Small functional issues >+ >+The most common area of disagreements which happen in code reviews, are >+differing opinions on whether small functional issues in a patch series have

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

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

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: > I have a multi-function PCI device, behind a PCI bridge, that normally > I assign to a single domain. But now it fails with: > > (XEN) [VT-D]d14: :04:00.0 owned by d0!<0>assign :05:00.0 to dom14 > failed (-22) I've tried this out

[Xen-devel] [PATCH] x86/smpboot: Use printk_once() rather than opencoding it

Shrink the text to be less verbose. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/smpboot.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c index a7e7013097..7

[Xen-devel] [PATCH] Coverity: Improve model for {, un}map_domain_page()

The first attempt resulted in several "Free of address-of expression (BAD_FREE)" issues, because of code which relies on the fact that any pointer in the same page is ok to pass to unmap_domain_page() Model this property to remove the issues. Coverity IDs: 1135356 113536{0,1} 1401300 141809{0,1}

Re: [Xen-devel] [XEN PATCH v2 2/6] xen: Have Kconfig check $(CC)'s version

On Fri, Jan 03, 2020 at 05:42:18PM +0100, Jan Beulich wrote: > On 17.12.2019 11:58, Anthony PERARD wrote: > > --- a/xen/Kconfig > > +++ b/xen/Kconfig > > @@ -4,9 +4,26 @@ > > # > > mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration" > > > > +source "scripts/Kconfig.include" > > + > > co

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote: > On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: > > I have a multi-function PCI device, behind a PCI bridge, that normally > > I assign to a single domain. But now it fails with: > > > > (XEN) [VT-D]d14: :04:00.0 owned by d

Re: [Xen-devel] [PATCH V6 3/4] x86/mm: Pull out the p2m specifics from p2m_init_altp2m_ept

On 1/6/20 11:55 AM, Alexandru Stefan ISAILA wrote: > On 24.12.2019 12:15, George Dunlap wrote: >> On 12/24/19 10:08 AM, Alexandru Stefan ISAILA wrote: >>> >>> >>> On 24.12.2019 10:01, George Dunlap wrote: On 12/23/19 2:04 PM, Alexandru Stefan ISAILA wrote: Why? >>> >>> This was

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On Mon, Jan 06, 2020 at 03:04:20PM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote: > > On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: > > > I have a multi-function PCI device, behind a PCI bridge, that normally > > > I assign to a sin

Re: [Xen-devel] [PATCH V6 3/4] x86/mm: Pull out the p2m specifics from p2m_init_altp2m_ept

On 1/6/20 11:55 AM, Alexandru Stefan ISAILA wrote: > On 24.12.2019 12:15, George Dunlap wrote: >> On 12/24/19 10:08 AM, Alexandru Stefan ISAILA wrote: >>> >>> >>> On 24.12.2019 10:01, George Dunlap wrote: On 12/23/19 2:04 PM, Alexandru Stefan ISAILA wrote: Why? >>> >>> This was

Re: [Xen-devel] [PATCH] libxl: create backend/ xenstore dir for driver domains

Marek Marczykowski-Górecki writes ("[PATCH] libxl: create backend/ xenstore dir for driver domains"): > Cleaning up backend xenstore entries is a responsibility of the backend. > When backend lives outside of dom0, the domain needs proper permissions > to do it. Normally it is given permission to

Re: [Xen-devel] [PATCH 2/4] x86/mm: rename and tidy create_pae_xen_mappings()

On 20.12.2019 16:33, Andrew Cooper wrote: > On 20/12/2019 14:19, Jan Beulich wrote: >> After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page >> table") and the removal of 32-bit support the function doesn't modify >> state anymore, and hence its name has been misleading. Change its

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On Mon, Jan 06, 2020 at 03:16:11PM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Jan 06, 2020 at 03:04:20PM +0100, Marek Marczykowski-Górecki wrote: > > On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote: > > > On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: > > > > I have a m

Re: [Xen-devel] [XEN PATCH 2/2] automation: Cache sub-project git tree in build jobs

On Fri, Jan 03, 2020 at 02:29:07PM +, Wei Liu wrote: > On Thu, Dec 19, 2019 at 02:42:17PM +, Anthony PERARD wrote: > > GitLab have a caching capability, see [1]. Let's use it to avoid using > > Internet too often. > > > > The cache is setup so that when xen.git/Config.mk is changed, the >

Re: [Xen-devel] [XEN PATCH v2 2/6] xen: Have Kconfig check $(CC)'s version

On 06.01.2020 15:01, Anthony PERARD wrote: > On Fri, Jan 03, 2020 at 05:42:18PM +0100, Jan Beulich wrote: >> On 17.12.2019 11:58, Anthony PERARD wrote: >>> --- a/xen/Kconfig >>> +++ b/xen/Kconfig >>> @@ -4,9 +4,26 @@ >>> # >>> mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration" >>> >>> +

Re: [Xen-devel] [XEN PATCH v2 0/6] xen: Kconfig update with few extra

Hi, On 06/01/2020 10:50, Anthony PERARD wrote: On Mon, Dec 23, 2019 at 06:44:11PM +0100, Julien Grall wrote: Hi, On 17/12/2019 11:58, Anthony PERARD wrote: Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.build-system-xen-kconfig-

Re: [Xen-devel] [PATCH] xsm: hide detailed Xen version from unprivileged guests

On 06/01/2020 11:28, George Dunlap wrote: > On 12/19/19 11:15 PM, Andrew Cooper wrote: >> On 19/12/2019 11:35, Jan Beulich wrote: >> XENVER_changeset >> XENVER_commandline >> XENVER_build_id >> >> Return a more customer friendly empty string instead of "" >> whic

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On 06.01.2020 15:04, Marek Marczykowski-Górecki wrote: > On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote: >> On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote: >>> I have a multi-function PCI device, behind a PCI bridge, that normally >>> I assign to a single domain. But now it fai

Re: [Xen-devel] [PATCH] libxl: create backend/ xenstore dir for driver domains

On Mon, Jan 06, 2020 at 02:20:46PM +, Ian Jackson wrote: > Marek Marczykowski-Górecki writes ("[PATCH] libxl: create backend/ xenstore > dir for driver domains"): > > Cleaning up backend xenstore entries is a responsibility of the backend. > > When backend lives outside of dom0, the domain nee

Re: [Xen-devel] [PATCH] xsm: hide detailed Xen version from unprivileged guests

On 06.01.2020 15:35, Sergey Dyasli wrote: > On 06/01/2020 11:28, George Dunlap wrote: >> On 12/19/19 11:15 PM, Andrew Cooper wrote: >>> On 19/12/2019 11:35, Jan Beulich wrote: >>> XENVER_changeset >>> XENVER_commandline >>> XENVER_build_id >>> >>> Return a more custo

Re: [Xen-devel] [PATCH] x86/smpboot: Use printk_once() rather than opencoding it

On 06.01.2020 14:26, Andrew Cooper wrote: > Shrink the text to be less verbose. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-dev

[Xen-devel] [PATCH v2 0/3] x86/mm: (remaining) XSA-299 / 309 / 310 follow-up

Addressing a few assorted aspects I've noticed during the investigations / reviews. 1: mod_l_entry() have no need to use __copy_from_user() 2: rename and tidy create_pae_xen_mappings() 3: re-order a few conditionals Jan ___ Xen-devel mailing list Xen-d

[Xen-devel] [PATCH v2 2/3] x86/mm: rename and tidy create_pae_xen_mappings()

After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page table") and the removal of 32-bit support the function doesn't modify state anymore, and hence its name has been misleading. Change its name, constify parameters and a local variable, and make it return bool. Also drop the call

[Xen-devel] [PATCH v2 1/3] x86/mm: mod_l_entry() have no need to use __copy_from_user()

mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86: Fold page_info lock into type_info"), and the other three never had such a need, at least going back as far as 3.2.0. Replace the uses by newly introduced le_access_once(). Signed-off-by: Jan Beulich --- v2: Use ACCESS_ONCE()

[Xen-devel] [PATCH v2 3/3] x86/mm: re-order a few conditionals

is_{hvm,pv}_*() can be expensive now, so where possible evaluate cheaper conditions first. Signed-off-by: Jan Beulich --- v2: New. --- I couldn't really decide whether to drop the two involved unlikely(). --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1588,7 +1588,7 @@ static int promote_l3

Re: [Xen-devel] [PATCH] libxl: create backend/ xenstore dir for driver domains

Adding Roger to the CC. Marek Marczykowski-Górecki writes ("Re: [PATCH] libxl: create backend/ xenstore dir for driver domains"): > On Mon, Jan 06, 2020 at 02:20:46PM +, Ian Jackson wrote: > > Marek Marczykowski-Górecki writes ("[PATCH] libxl: create backend/ xenstore > > dir for driver doma

Re: [Xen-devel] [PATCH] Coverity: Improve model for {, un}map_domain_page()

On 06.01.2020 14:28, Andrew Cooper wrote: > The first attempt resulted in several "Free of address-of > expression (BAD_FREE)" issues, because of code which relies on the fact that > any pointer in the same page is ok to pass to unmap_domain_page() > > Model this property to remove the issues. >

[Xen-devel] [PATCH 5/6] x86/boot: Don't map 0 during boot

In particular, it causes accidental NULL pointer dereferences to go unnoticed. The majority of the early operation takes place either in Real mode, or Protected Unpaged mode. The only bit which requires pagetable mappings is the trampoline transition into Long mode and jump to the higher mappings

[Xen-devel] [PATCH 2/6] x86/boot: Map the trampoline as read-only

c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set, removed the final writes which occurred between enabling paging and switching to the high mappings. There don't plausibly need to be any memory writes in few instructions is takes to perform this transition. As a consequence,

[Xen-devel] [PATCH 4/6] x86/boot: Clean up l?_bootmap[] construction

The need for Xen to be identity mapped into the bootmap is not obvious, and differs between the MB and EFI boot paths. Furthermore, the EFI side is further complicated by spraying non-identity aliases into the mix. Simplify the EFI bootmap construction code to make exactly one identity-map of Xen

[Xen-devel] [PATCH 0/6] x86/boot: Remove mappings at 0

This is the (long overdue) series which finally removes the mapping at 0 during early boot, which has bitten us in the past. It also removes an RWX gadget which persists past boot in the idle pagetables. Most of the complexity was down to the differing (and hard-to-follow) uses of the bootmap. I

[Xen-devel] [PATCH 6/6] x86/boot: Drop INVALID_VCPU

Now that NULL will fault at boot, there is no need for a special constant to signify "current not set up yet". Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/cpu/mcheck/mce.c | 2 +- xen/arch/x86/domain_page.c| 2 +- xen/arch/x86/setup.c

[Xen-devel] [PATCH 1/6] x86/boot: Check for E820_RAM earlier when searching the E820

There is no point performing the masking calculations if we are going to throw the result away. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/setup.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) di

[Xen-devel] [PATCH 3/6] x86/boot: Remove the preconstructed low 16M superpage mappings

First, it is undefined to have superpages and MTRRs disagree on cacheability boundaries, and nothing this early in boot has checked that it is safe to use superpages here. Furthermore, nothing actually uses the mappings on boot. Build these entries in the directmap when walking the E820 table alo

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

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

Re: [Xen-devel] [PATCH] libxl: create backend/ xenstore dir for driver domains

On Mon, Jan 06, 2020 at 03:40:22PM +, Ian Jackson wrote: > Adding Roger to the CC. > > Marek Marczykowski-Górecki writes ("Re: [PATCH] libxl: create backend/ > xenstore dir for driver domains"): > > On Mon, Jan 06, 2020 at 02:20:46PM +, Ian Jackson wrote: > > > Marek Marczykowski-Górecki

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: mod_l_entry() have no need to use __copy_from_user()

On 06/01/2020 15:34, Jan Beulich wrote: > --- a/xen/include/asm-x86/page.h > +++ b/xen/include/asm-x86/page.h > @@ -55,6 +55,16 @@ > #define l4e_write(l4ep, l4e) \ > pte_write(&l4e_get_intpte(*(l4ep)), l4e_get_intpte(l4e)) > > +/* Type-correct ACCESS_ONCE() wrappers for PTE accesses. */ > +

Re: [Xen-devel] [PATCH v2 2/3] x86/mm: rename and tidy create_pae_xen_mappings()

On 06/01/2020 15:35, Jan Beulich wrote: > After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page > table") and the removal of 32-bit support the function doesn't modify > state anymore, and hence its name has been misleading. Change its name, > constify parameters and a local variabl

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: mod_l_entry() have no need to use __copy_from_user()

On 06.01.2020 17:09, Andrew Cooper wrote: > On 06/01/2020 15:34, Jan Beulich wrote: >> --- a/xen/include/asm-x86/page.h >> +++ b/xen/include/asm-x86/page.h >> @@ -55,6 +55,16 @@ >> #define l4e_write(l4ep, l4e) \ >> pte_write(&l4e_get_intpte(*(l4ep)), l4e_get_intpte(l4e)) >> >> +/* Type-corr

Re: [Xen-devel] [PATCH v3] CODING_STYLE: Document how to handle unexpected conditions

On 12/10/19 1:46 PM, Jan Beulich wrote: > On 10.12.2019 11:56, George Dunlap wrote: >> On 12/9/19 1:50 PM, Jan Beulich wrote: >>> On 09.12.2019 12:29, George Dunlap wrote: --- a/CODING_STYLE +++ b/CODING_STYLE @@ -133,3 +133,97 @@ the end of files. It should be: * indent-tabs

Re: [Xen-devel] [PATCH] livepatch: use proper rc variable in livepatch_do_action()

On Mon, Jan 06, 2020 at 12:56:23PM +, Pawel Wieczorkiewicz wrote: > Fix c&p bug in the livepatch_do_action() code of > LIVEPATCH_ACTION_REPLACE case. > The correct variable handling return code of revert action is > other->rc in this case. > > Coverity-ID: 1457467 > Fixes: 6047104c3c ("livepat

Re: [Xen-devel] [PATCH v3] CODING_STYLE: Document how to handle unexpected conditions

On 06.01.2020 17:19, George Dunlap wrote: > On 12/10/19 1:46 PM, Jan Beulich wrote: >> On 10.12.2019 11:56, George Dunlap wrote: >>> On 12/9/19 1:50 PM, Jan Beulich wrote: On 09.12.2019 12:29, George Dunlap wrote: > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -133,3 +133,97 @@ the

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: mod_l_entry() have no need to use __copy_from_user()

On 06/01/2020 16:18, Jan Beulich wrote: > On 06.01.2020 17:09, Andrew Cooper wrote: >> On 06/01/2020 15:34, Jan Beulich wrote: >>> --- a/xen/include/asm-x86/page.h >>> +++ b/xen/include/asm-x86/page.h >>> @@ -55,6 +55,16 @@ >>> #define l4e_write(l4ep, l4e) \ >>> pte_write(&l4e_get_intpte(*(l4

[Xen-devel] [PATCH v3 0/8] x86emul: further work

Some of the later patches are RFC, for varying reasons (see there). 1: x86: determine HAVE_AS_* just once 2: x86: move back clang no integrated assembler tests 3: x86emul: support MOVDIRI insn 4: x86emul: support MOVDIR64B insn 5: x86/HVM: scale MPERF values reported to guests (on AMD) 6: x86emul:

[Xen-devel] [PATCH v3 1/8] x86: determine HAVE_AS_* just once

With the exception of HAVE_AS_QUOTED_SYM, populate the results into a generated header instead of (at least once per [sub]directory) into CFLAGS. This results in proper rebuilds (via make dependencies) in case the compiler used changes between builds. It additionally eases inspection of which assem

[Xen-devel] [PATCH v3 3/8] x86emul: support MOVDIRI insn

Note that SDM revision 070 doesn't specify exception behavior for ModRM.mod != 0b11; assuming #UD here. Signed-off-by: Jan Beulich --- v4: Split MOVDIRI and MOVDIR64B. Re-base. v3: Update description. --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emul

[Xen-devel] [PATCH v3 2/8] x86: move back clang no integrated assembler tests

This largely reverts f19af2f1138e ("x86: re-order clang no integrated assembler tests"): Other CFLAGS setup would better happen first, in case any of it affects the behavior of the integrated assembler. The comment addition of course doesn't get undone. The only remaining as-option-add invocation g

[Xen-devel] [PATCH RFC v3 4/8] x86emul: support MOVDIR64B insn

Note that SDM revision 070 doesn't specify exception behavior for ModRM.mod != 0b11; assuming #UD here. Signed-off-by: Jan Beulich --- RFC: Yet to be tested (once SDE supports it). --- v4: Split MOVDIRI and MOVDIR64B. Switch to using ->rmw(). Re-base. v3: Update description. --- a/tools/tests/x8

[Xen-devel] [PATCH v3 5/8] x86/HVM: scale MPERF values reported to guests (on AMD)

AMD's PM specifies that MPERF (and its r/o counterpart) reads are affected by the TSC ratio. Hence when processing such reads in software we too should scale the values. While we don't currently (yet) expose the underlying feature flags, besides us allowing the MSRs to be read nevertheless, RDPRU i

Re: [Xen-devel] [PATCH v2 3/3] x86/mm: re-order a few conditionals

On 06/01/2020 15:35, Jan Beulich wrote: > is_{hvm,pv}_*() can be expensive now, so where possible evaluate cheaper > conditions first. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper > --- > v2: New. > --- > I couldn't really decide whether to drop the two involved unlikely(). Personall

[Xen-devel] [PATCH RFC v3 6/8] x86emul: support RDPRU

While the PM doesn't say so, this assumes that the MPERF value read this way gets scaled similarly to its reading through RDMSR. Also introduce the SVM related constants at this occasion. Signed-off-by: Jan Beulich --- RFC: Andrew promised to take care of the CPUID side of this; will need r

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

On Mon, Jan 06, 2020 at 03:38:46PM +0100, Jan Beulich wrote: > On 06.01.2020 15:04, Marek Marczykowski-Górecki wrote: > > Is the patch from your other message still relevant? > > ... what this patch deals with. The answer to your question is "yes", > also in light of your subsequent replies, albei

[Xen-devel] [PATCH RFC v3 8/8] x86emul: support MCOMMIT

The dependency on a new EFER bit implies that we need to set that bit ourselves in order to be able to successfully invoke the insn. Also once again introduce the SVM related constants at this occasion. Signed-off-by: Jan Beulich --- RFC: The exact meaning of the PM stating "any errors encounter

[Xen-devel] [PATCH v3 7/8] x86/HVM: don't needlessly intercept APERF/MPERF/TSC MSR reads

If the hardware can handle accesses, we should allow it to do so. This way we can expose EFRO to HVM guests, and "all" that's left for exposing APERF/MPERF is to figure out how to handle writes to these MSRs. (Note that the leaf 6 guest CPUID checks will evaluate to false for now, as recalculate_mi

Re: [Xen-devel] [PATCH v3 0/8] x86emul: further work

On 06.01.2020 17:31, Jan Beulich wrote: > Some of the later patches are RFC, for varying reasons (see there). > > 1: x86: determine HAVE_AS_* just once > 2: x86: move back clang no integrated assembler tests > 3: x86emul: support MOVDIRI insn > 4: x86emul: support MOVDIR64B insn > 5: x86/HVM: scal

Re: [Xen-devel] [PATCH v3 1/8] x86: determine HAVE_AS_* just once

On 06/01/2020 16:34, Jan Beulich wrote: > With the exception of HAVE_AS_QUOTED_SYM, populate the results into a > generated header instead of (at least once per [sub]directory) into > CFLAGS. This results in proper rebuilds (via make dependencies) in case > the compiler used changes between builds.

Re: [Xen-devel] [PATCH v3 1/8] x86: determine HAVE_AS_* just once

On 06.01.2020 17:41, Andrew Cooper wrote: > On 06/01/2020 16:34, Jan Beulich wrote: >> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a >> generated header instead of (at least once per [sub]directory) into >> CFLAGS. This results in proper rebuilds (via make dependencies) in c

Re: [Xen-devel] [PATCH v3 3/8] x86emul: support MOVDIRI insn

On 06/01/2020 16:35, Jan Beulich wrote: > Note that SDM revision 070 doesn't specify exception behavior for > ModRM.mod != 0b11; assuming #UD here. Don't you mean mod == 11 here? My Jacobsville SDP does have MOVDIRI, and 0F 38 F9 C0 does result in #UD, whereas the example from the test emulator b

Re: [Xen-devel] [PATCH v3 3/8] x86emul: support MOVDIRI insn

On 06.01.2020 17:56, Andrew Cooper wrote: > On 06/01/2020 16:35, Jan Beulich wrote: >> Note that SDM revision 070 doesn't specify exception behavior for >> ModRM.mod != 0b11; assuming #UD here. > > Don't you mean mod == 11 here? Oh, yes, of course I do - corrected. Jan _

[Xen-devel] [PATCH] tools/save: Drop unused parameters from xc_domain_save()

XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015), XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA since c/s 087d43326 (2007). Drop the constants, and code which sets them. The separate hvm parameter (appeared in c/s d11bec8a1, 2007 and ultimately redundant with XC

Re: [Xen-devel] [PATCH] x86/shim: Short circuit control/hardware checks in PV_SHIM_EXCLUSIVE builds

On 06/01/2020 10:13, Jan Beulich wrote: > On 03.01.2020 21:07, Andrew Cooper wrote: >> --- a/xen/include/xen/sched.h >> +++ b/xen/include/xen/sched.h >> @@ -963,10 +963,22 @@ void watchdog_domain_destroy(struct domain *d); >> *(that is, this would not be suitable for a driver domain) >> *

Re: [Xen-devel] [PATCH v5 1/6] arm/arm64/xen: hypercall.h add includes guards

On Thu, 2 Jan 2020, Pavel Tatashin wrote: > The arm and arm64 versions of hypercall.h are missing the include > guards. This is needed because C inlines for privcmd_call are going to > be added to the files. > > Signed-off-by: Pavel Tatashin > Reviewed-by: Julien Grall Acked-by: Stefano Stabell

[Xen-devel] [PATCH] xen/cpupool: Fold error paths in cpupool_create()

The compiler can't fold because of the write to *perr in the first hunk. No functional change, but slightly better compiled code. Signed-off-by: Andrew Cooper --- CC: Juergen Gross CC: Dario Faggioli --- xen/common/cpupool.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-

Re: [Xen-devel] REGRESSION: Xen 4.13 RC5 fails to bootstrap Dom0 on ARM

On Wed, 1 Jan 2020, Julien Grall wrote: > On 31/12/2019 22:48, Roman Shaposhnik wrote: > > Hi! > > Hi, > > > > > Good news: one that type was fixed Xen booted just fine and detected > > all the available 2G of memory. > > Thank you for testing. @Stefano are you going to prepare and submit the p

[Xen-devel] [PATCH] xen/arm: during efi boot, improve the check for usable memory

When booting via EFI, the EFI memory map has information about memory regions and their type. Improve the check for the type and attribute of each memory region to figure out whether it is usable memory or not. This patch brings the check on par with Linux and makes more memory reusable as normal m

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

flight 145664 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145664/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861 test-amd64-i386-f

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

On 09/12/2019 12:11, Jan Beulich wrote: > On 06.12.2019 22:02, Andrew Cooper wrote: >> On 12/11/2019 14:03, Jan Beulich wrote: >>> Bottom line - I'm half convinced and willing to give my ack, but >>> I'm not convinced you truly thought through the longer term >>> consequences. I'd therefore be far

Re: [Xen-devel] [PATCH RFC v3 4/8] x86emul: support MOVDIR64B insn

On 06/01/2020 16:36, Jan Beulich wrote: > Note that SDM revision 070 doesn't specify exception behavior for > ModRM.mod != 0b11; assuming #UD here. > > Signed-off-by: Jan Beulich > --- > RFC: Yet to be tested (once SDE supports it). Do you have any plans for how to support ENQCMD{,S} which are ju

Re: [Xen-devel] [PATCH RFC v3 8/8] x86emul: support MCOMMIT

On 06/01/2020 16:39, Jan Beulich wrote: > The dependency on a new EFER bit implies that we need to set that bit > ourselves in order to be able to successfully invoke the insn. > > Also once again introduce the SVM related constants at this occasion. > > Signed-off-by: Jan Beulich > --- > RFC: The

Re: [Xen-devel] [PATCH RFC v3 6/8] x86emul: support RDPRU

On 06/01/2020 16:37, Jan Beulich wrote: > While the PM doesn't say so, this assumes that the MPERF value read this > way gets scaled similarly to its reading through RDMSR. > > Also introduce the SVM related constants at this occasion. > > Signed-off-by: Jan Beulich > --- > RFC: Andrew promised to

Re: [Xen-devel] [PATCH] xen/arm: during efi boot, improve the check for usable memory

Hi Stefano, On 06/01/2020 18:26, Stefano Stabellini wrote: When booting via EFI, the EFI memory map has information about memory regions and their type. Improve the check for the type and attribute of each memory region to figure out whether it is usable memory or not. This patch brings the chec

[Xen-devel] Community Call: Call for Agenda Items and call details for Jan 9, 16:00 - 17:00 UTC

Dear community members,   I hope you all had a restful holiday period and a Happy New Year! Please send me agenda items for this Thursday's community call (we agreed to move it by 1 week) preferably by Wednesday! A draft agenda is at  https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-A

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

flight 145681 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145681/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

Re: [Xen-devel] [PATCH] xen/arm: vgic-v3: Fix the typo of GICD IRQ active status range

On Sat, 28 Dec 2019, Wei Xu wrote: > Hi Julien, > > On 2019/12/28 16:09, Julien Grall wrote: > > Hi, > > > > On 28/12/2019 03:08, Wei Xu wrote: > > > This patch fixes the typo about the active status range of an IRQ > > > via GICD. Otherwise it will be failed to handle the mmio access and > > > i

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

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

Re: [Xen-devel] [RFC] Integrate CoC, Governance, Security Policy and other key documents into sphinx docs

On Wed, 18 Dec 2019, Lars Kurth wrote: > Hi all, > > now that 4.13 is out of the way I wanted to get the CoC discussion closed - > see > https://lists.xenproject.org/archives/html/xen-devel/2019-12/threads.html#00926, > which means I need ACKs or final suggestions. The next step would be to >

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

flight 145685 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145685/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

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

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

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Jan 9, 16:00 - 17:00 UTC

On 06/01/2020 19:56, Lars Kurth wrote: > Dear community members, >   > I hope you all had a restful holiday period and a Happy New Year! > > Please send me agenda items for this Thursday's community call (we agreed to > move it by 1 week) preferably by Wednesday! > > A draft agenda is at  > https

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

flight 145692 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145692/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

  1   2   >