flight 135462 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 127792
build-i386-xsm
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-arm64-arm64-libvirt-xsm
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linu
flight 135453 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135453/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 107 leak-check/checkfail REGR. vs. 132889
build-amd64-pre
flight 135456 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 135426
test-amd6
On 02/05/2019 23:40, Tamas K Lengyel wrote:
>> @@ -211,13 +212,14 @@ struct vm_event_regs_x86 {
>> struct vm_event_x86_selector_reg fs;
>> struct vm_event_x86_selector_reg gs;
>> uint64_t shadow_gs;
>> +uint16_t gdtr_limit;
> Whoops, just noticed that limit actually needs 20-bits
On Thu, May 2, 2019 at 5:42 PM Andrew Cooper wrote:
>
> On 02/05/2019 23:40, Tamas K Lengyel wrote:
> >> @@ -211,13 +212,14 @@ struct vm_event_regs_x86 {
> >> struct vm_event_x86_selector_reg fs;
> >> struct vm_event_x86_selector_reg gs;
> >> uint64_t shadow_gs;
> >> +uint16_t g
flight 135450 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135450/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133734
Test
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
v2: add gdtr limit
v3: use ui
On Thu, May 2, 2019 at 3:42 PM Tamas K Lengyel wrote:
>
> Receiving this register is useful for introspecting 32-bit Windows when the
> event being trapped happened while in ring3.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Coo
On Thu, 2 May 2019, Jan Beulich wrote:
> >>> On 02.05.19 at 11:02, wrote:
> > On 5/2/19 8:30 AM, Jan Beulich wrote:
> > On 02.05.19 at 00:44, wrote:
> >>> Hi Jan, I have a question on the PDX code.
> >>>
> >>> The PDX initialization is a bit different between x86 and ARM, but it
> >>> follows
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
The comment being dropped is incorrect since it's now out-of-date.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
This series i
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we copy a
On 5/3/19 12:42 AM, Tamas K Lengyel wrote:
> Receiving this register is useful for introspecting 32-bit Windows when the
> event being trapped happened while in ring3.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: We
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/include/asm-x86/mem_sharing.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
b/xen/include/asm-x86/mem
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: George D
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
v2: add gdtr limit
---
xen/a
(+ Wei)
On 5/2/19 5:55 PM, Viktor Mitin wrote:
Hi Julien,
Hi,
Please find trace log below:
root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x78266000
So this is a data abort when trying to access VA 0x361700 (it i
On Thu, 2 May 2019, Jan Beulich wrote:
> >>> On 30.04.19 at 23:02, wrote:
> > Now that map_mmio_regions takes a p2mt parameter, there is no need to
> > keep "mmio" in the name. The p2mt parameter does a better job at
> > expressing what the mapping is about. Let's save the environment 5
> > charac
On Thu, 2 May 2019, Jan Beulich wrote:
> >>> On 30.04.19 at 23:02, wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -79,8 +79,11 @@ static int __init modify_identity_mmio(struct domain *d,
> > unsigned long pfn,
> >
> > for ( ; ; )
> > {
>
flight 135446 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125575
test
No functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index c8bcad33..10ab65a8 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -54,7 +54,6 @@ set -e -o posi
It is annoying that mg-repro-flight cannot run a build for you too.
Fix this.
This is on xenbits in
https://xenbits.xen.org/git-http/people/iwj/osstest.git
xenbits.xen.org:/home/iwj/ext/osstest.git
etc. as the branch
wip.repro-flight-builds.v1
Ian Jackson (9):
mg-execute-flight: Save an m
This may be useful for some things. For example, it will be used in
just a moment.
Signed-off-by: Ian Jackson
---
mg-execute-flight | 1 +
1 file changed, 1 insertion(+)
diff --git a/mg-execute-flight b/mg-execute-flight
index b3cdf431..391f4810 100755
--- a/mg-execute-flight
+++ b/mg-execute-
No functional change with existing call sites.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index b41bf478..d63e29b6 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -46,7 +46,7 @@ END
}
This makes debugging it easier. No functional change with zero or one
occurrences of -D.
Signed-off-by: Ian Jackson
---
cs-adjust-flight | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index badabeff..cc1684b4
No functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 10ab65a8..b41bf478 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -115,6 +115,13 @@ compute_adjusts ()
No functional change.
Signed-off-by: Ian Jackson
---
cs-adjust-flight | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index ee1d917c..badabeff 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -194,10 +194,8 @@ s
This allows a single command to repro a particular job with a variety
of different source code.
The implementation technique is:
- run the build job in a separate flight, so that it can run
with a separate task which gives its host up after the build
- do much of the heavy lifting of runva
Signed-off-by: Ian Jackson
---
mg-repro-setup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 6ed4d85e..c8bcad33 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -33,7 +33,7 @@ usage () { cat < is \`host')
OPTIONs
- -t est
No significant functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index d63e29b6..2e1d3b88 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -167,6 +167,9 @@ while [ $# -ne 0
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main difference between SCIF and SCIFA interfaces
from "scif-uart" driver's p
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_PRINTK_VERSION" config option to choose which
interface version sho
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c4,A
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
-
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatible string
This patch makes possible to use existing driver for Ren
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager (R
Hi Julien,
Please find trace log below:
root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x78266000
(XEN) 0TH[0x0] = 0x78265f7f
(XEN) 1ST[0x0] = 0x78262f7f
(XEN) 2ND[0x1] = 0x00407825ff7f
(XEN) 3RD[0x
flight 135444 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 124921
buil
Following QEMU's commit 79d77bcd36 (configure: Remove --source-path
option), Xen's build system fails to build qemu-xen. The --source-path
option gives redundant information about the location of the sources
so simply remove it. (configure already looks at its $0 to find the
source-path.)
Signed-o
flight 135448 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 135251
build-amd64-xsm
Hi,
On 5/2/19 3:50 PM, Viktor Mitin wrote:
Adding Xen maintainers to this email CC.
Thanks
On Thu, May 2, 2019 at 5:08 PM Viktor Mitin wrote:
Hi All,
Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested:
On Thu, 2019-05-02 at 15:08 +0100, Andrew Cooper wrote:
> Sadly it cant.
>
> We have a number of alignment issues (well - confusions at least), most
> obviously that trampoline_{start,end} in the linked Xen image has no
> particular alignment, but the relocated trampoline_start has a 4k
> requirem
>>> On 30.04.19 at 23:02, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -571,12 +571,24 @@ struct xen_domctl_bind_pt_irq {
> */
> #define DPCI_ADD_MAPPING 1
> #define DPCI_REMOVE_MAPPING 0
> +/*
> + * Default memory policy. Corresponds to:
> +
>>> On 30.04.19 at 23:02, wrote:
> Now that map_mmio_regions takes a p2mt parameter, there is no need to
> keep "mmio" in the name. The p2mt parameter does a better job at
> expressing what the mapping is about. Let's save the environment 5
> characters at a time.
But as per the cover letter the
>>> On 30.04.19 at 23:02, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -79,8 +79,11 @@ static int __init modify_identity_mmio(struct domain *d,
> unsigned long pfn,
>
> for ( ; ; )
> {
> -rc = map ? map_mmio_regions(d, _gfn(pfn), nr
>>> On 05.04.19 at 09:01, wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -503,7 +503,7 @@ static struct amd_iommu *_find_iommu_for
> {
> struct amd_iommu *iommu;
>
> -list_for_each_entry ( i
>>> On 10.04.19 at 11:37, wrote:
> Do this statically, which will allow accessing the (empty) list even
> without having come through acpi_ivrs_init().
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -36,7 +
Adding Xen maintainers to this email CC.
Thanks
On Thu, May 2, 2019 at 5:08 PM Viktor Mitin wrote:
>
> Hi All,
>
> Please be aware that we have tried Xen ARM64 build with
> CONFIG_COVERAGE feature enabled. The build environment is next:
> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
>
>>> On 09.04.19 at 14:03, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct
> p2m_domain *hp2m,
> gfn_t gfn2 = _gfn(gfn_l & mask);
> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>>> On 09.04.19 at 14:03, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -265,31 +265,27 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct
> p2m_domain *hp2m,
> unsigned int page_order;
> unsigned long gfn_l = gfn_x(gfn);
> int rc;
> +
On 01/05/2019, 12:56, "Rich Persaud" wrote:
> On May 1, 2019, at 14:37, Lars Kurth wrote:
>
> Rich,
> as nobody replied to the mail, I am inclined to dismiss the proposal of
ANN for now
> Lars
What do you think about the suggestion to apply a tag ("ANNOUNCE"?) fo
When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.
As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
this is done this
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 15:25
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: p2m_ram_ro is incompatible with dev
>>> On 02.05.19 at 16:12, wrote:
> Actually, since global_logdirty is somewhat transient should we not also
> have a check to prevent p2m_ram_logdirty from being set for a domain with
> assigned devices and shared EPT?
Probably (if we indeed don't), but imo not in this patch.
Jan
__
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 14:57
> To: Andrew Cooper
> Cc: Paul Durrant ; Roger Pau Monne
> ; Wei Liu
> ; George Dunlap ; xen-devel
> de...@lists.xenproject.org>
> Subject: Re: [PATCH] x86/HVM: p2m_ram_ro is incompatible with
On Thu, 2 May 2019 06:46:23 -0700
Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> > Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> > them use it. apply_to_pte_range() should stop computing it as well. Should
> > help us s
From: Oleksandr Tyshchenko
Hello, all.
The purpose of this small series is to add minimal required support for Xen to
be able to
handle device-tree nodes with "interrupts-extended" property [1].
The reason:
Xen expects to see "interrupts" property when parsing host device-tree.
But, there are
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
---
xen/common/device_tree.c | 7 +++
xen/include/xen/device_tree.h | 19 +++
2 files changed, 26 insertions(+)
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family,
which is mandatory device for Xen us
On 02/05/2019 14:50, Jan Beulich wrote:
On 02.05.19 at 15:27, wrote:
>> --- a/xen/arch/x86/boot/trampoline.S
>> +++ b/xen/arch/x86/boot/trampoline.S
>> @@ -38,6 +38,12 @@
>>
>> .code16
>>
>> +/*
>> + * do_boot_cpu() programs the Startup-IPI to point here. Due to the SIPI
>> + *
Hi All,
Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested: xen-4.12-stable, xen-4.13-staging
Board: H3ULCB, R-Car H3 Ver.2.0
Poky: Yocto Project Reference Distro 2.4.2
Compiler: aarch64-poky-linux-gcc (Linaro
On 05/02/2019 07:16 PM, Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
>> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
>> them use it. apply_to_pte_range() should stop computing it as well. Should
>> help us save some cycl
Drop the pgtable_t variable from all implementation for pte_fn_t as none of
them use it. apply_to_pte_range() should stop computing it as well. Should
help us save some cycles.
Signed-off-by: Anshuman Khandual
Cc: Ard Biesheuvel
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas
>>> On 02.05.19 at 15:42, wrote:
> On 02/05/2019 14:16, Jan Beulich wrote:
> On 02.05.19 at 14:59, wrote:
>>> On 02/05/2019 13:29, Jan Beulich wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1450,17 +1450,36 @@ static int assign_device(struct
On Thu, May 2, 2019 at 7:30 AM Jan Beulich wrote:
>
> >>> On 02.05.19 at 15:09, wrote:
> > That said I don't have a use for idt and gdtr_limit that warrants
> > having to receive it via the vm_event structure
>
> So what use if the GDT base without the limit? Are you silently
> assuming all prese
>>> On 02.05.19 at 15:27, wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -38,6 +38,12 @@
>
> .code16
>
> +/*
> + * do_boot_cpu() programs the Startup-IPI to point here. Due to the SIPI
> + * format, the relocated entrypoint must be 4k aligne
On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> them use it. apply_to_pte_range() should stop computing it as well. Should
> help us save some cycles.
You didn't add Martin Schwidefsky for some reaso
On 02/05/2019 14:16, Jan Beulich wrote:
On 02.05.19 at 14:59, wrote:
>> On 02/05/2019 13:29, Jan Beulich wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
>>> if ( !iommu_enabled ||
>>> On 02.05.19 at 15:12, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
>> Sent: 02 May 2019 13:28
>>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1310,8 +1310,11 @@ static void __hwdom_ini
>>> On 02.05.19 at 15:09, wrote:
> That said I don't have a use for idt and gdtr_limit that warrants
> having to receive it via the vm_event structure
So what use if the GDT base without the limit? Are you silently
assuming all presently loaded selectors are (still) within limits?
Jan
___
>>> On 02.05.19 at 15:23, wrote:
> My point is, at the moment it's fine to skip idtr if it's not required
> by Jan, but if we do add either then let's please add both _base and _limit.
No, it's not a requirement I mean to put up (and I'm not in the
position to either, as I'm not the maintainer o
>>> On 02.05.19 at 15:08, wrote:
> On Thu, May 02, 2019 at 06:28:06AM -0600, Jan Beulich wrote:
>> There's an invocation of iommu_flush_all() immediately afterwards.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>
On 02/05/2019 13:44, Jan Beulich wrote:
On 02.05.19 at 13:52, wrote:
>> c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
>> CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
>> but didn't adjust the structure definition in cmdline.c
>>
>> This only fun
... because its already hard enough to follow. Cross reference the locations
in C which set the entrypoints up, and state the alignment requirements and
entry conditions.
Drop a redundant .align 16, and panic() in do_boot_cpu() if the AP trampoline
isn't set up properly rather than blindly contin
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 14:23
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH 4/9] x86/HVM: move NOFLUSH handling out of hv
On 5/2/19 4:09 PM, Tamas K Lengyel wrote:
On Thu, May 2, 2019 at 2:57 AM Jan Beulich wrote:
On 02.05.19 at 10:25, wrote:
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signe
>>> On 02.05.19 at 15:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 02 May 2019 13:20
>>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -2072,6 +2072,8 @@ static int hvmemul_write_cr(
>> HVMTRACE_LONG_2D(CR_WRITE, reg, TRC_PAR_LONG(val));
>>> On 02.05.19 at 14:59, wrote:
> On 02/05/2019 13:29, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
>> if ( !iommu_enabled || !hd->platform_ops )
>> return 0;
>>
On Thu, May 2, 2019 at 4:46 AM Andrew Cooper wrote:
>
> On 02/05/2019 00:52, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index 283eb7b34d..5154ecc2a8 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -779
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 02 May 2019 13:28
> To: xen-devel
> Cc: Kevin Tian
> Subject: [Xen-devel] [PATCH] VT-d: suppress individual flushes during hwdom
> setup
>
> There's an invocation o
On Thu, May 02, 2019 at 06:28:06AM -0600, Jan Beulich wrote:
> There's an invocation of iommu_flush_all() immediately afterwards.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1310,8 +1310,11 @@ static void __hwdom_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 13:20
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH 4/9] x86/HVM: move NOFLUSH handling out of hvm_set_cr3()
>
> The bit is m
On Thu, May 2, 2019 at 2:57 AM Jan Beulich wrote:
>
> >>> On 02.05.19 at 10:25, wrote:
> > On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
> >> Receiving this register is useful for introspecting 32-bit Windows when the
> >> event being trapped happened while in ring3.
> >>
> >> Signed-off-by: Tamas K
On 02/05/2019 13:29, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
> if ( !iommu_enabled || !hd->platform_ops )
> return 0;
>
> -/* Prevent device assign if mem pa
>>> On 02.05.19 at 14:47, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 02 May 2019 13:29
>>
>> --- a/xen/arch/x86/hvm/dm.c
>> +++ b/xen/arch/x86/hvm/dm.c
>> @@ -255,16 +255,32 @@ static int set_mem_type(struct domain *d
>>
>> mem_type = array_index_nospec(data->mem_type,
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 13:29
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH] x86/HVM: p2m_ram_ro is incompatible with device pass-through
>
> The wri
>>> On 02.05.19 at 13:52, wrote:
> c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
> CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
> but didn't adjust the structure definition in cmdline.c
>
> This only functions correctly because the affected fields
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and repr
The write-discard property of the type can't be represented in IOMMU
page table entries. Make sure the respective checks / tracking can't
race, by utilizing the domain lock. The other sides of the sharing/
paging/log-dirty exclusion checks should subsequently perhaps also be
put under that lock the
There's an invocation of iommu_flush_all() immediately afterwards.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1310,8 +1310,11 @@ static void __hwdom_init intel_iommu_hwd
setup_hwdom_pci_devices(d, setup_hwdom_device);
Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> On Thu, May 02, 2019 at 11:42:04AM +0100, Ian Jackson wrote:
> > Can we assume that memory exhaustion will always result in some
> > message from the memory
This allows in particular some streamlining of the TLB flushing code
paths.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -24,6 +24,11 @@
#define WRAP_MASK (0x03FFU)
#endif
+#ifndef CONFIG_PV
+# undef X86_CR4_PCIDE
+# define X86_CR4_PCIDE 0
+#e
PCID validly depends on LM, as it can be enabled in Long Mode only.
INVPCID, otoh, can be used not only without PCID enabled, but also
outside of Long Mode altogether. In both cases its functionality is
simply restricted to PCID 0, which is sort of expected as no other PCID
can be activated there.
Eliminate the not really useful local variable "old". Reduce the scope
of "page". Rename the latched "current".
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2290,10 +2290,8 @@ int hvm_set_cr0(unsigned long value, boo
int hvm_set_cr3(unsigned long va
There's no need to re-obtain a page reference if only bits not affecting
the address change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,7 +2320,7 @@ int hvm_set_cr3(unsigned long value, boo
}
if ( hvm_paging_enabled(v) && !paging_mod
While bits 11 and below are, it not used for other purposes, reserved
but ignored, bits beyond physical address width are supposed to raise
exceptions (at least in the non-nested case; I'm not convinced the
current nested SVM/VMX behavior of raising #GP(0) here is correct, but
that's not the subjec
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2072,6 +2072,8 @@ static int hvmemul_write_cr(
HVMTRACE_LONG_2D(CR_WRITE, r
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
d->arch.x87_fip_width = 4;
We really need to flush the TLB just once, if we do so with or after the
CR3 write. The only case where two flushes are unavoidable is when we
mean to turn off CR4.PGE (perhaps just temporarily; see the code
comment).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/fl
There's no need for it to be 64 bits wide - only the low twelve bits
of CR3 hold the PCID.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -103,7 +103,8 @@ static void do_tlb_flush(void)
void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
{
-
c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
but didn't adjust the structure definition in cmdline.c
This only functions correctly because the affected fields are at the end
of the structure, and cmdline
1 - 100 of 134 matches
Mail list logo
