On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
flight 130638 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On 11/19/18 at 11:16am, David Hildenbrand wrote:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 933cb3e45b98..093c9f917ed0 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -464,6 +464,8 @@ static int __init crash_save_vmcoreinfo_init(void)
> VMCOREINFO_NUM
On 20/11/2018 19:09, Wei Liu wrote:
> Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
> xen-init-dom0 accept an extra argument for UUID.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-
flight 130633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
Thanks for this patch!
> On Nov 19, 2018, at 2:16 AM, David Hildenbrand wrote:
>
> Mark inflated and never onlined pages PG_offline, to tell the world that
> the content is stale and should not be dumped.
>
> Cc: Xavier Deguillard
> Cc: Nadav Amit
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
flight 130520 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 11/19/18 at 11:16am, David Hildenbrand wrote:
> Right now, pages inflated as part of a balloon driver will be dumped
> by dump tools like makedumpfile. While XEN is able to check in the
> crash kernel whether a certain pfn is actuall backed by memory in the
> hypervisor (see xen_oldmem_pfn_is_ra
flight 130564 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130564/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On Tue, Nov 20, 2018 at 10:12 AM Jan Beulich wrote:
>
> >>> On 20.11.18 at 17:59, wrote:
> > On 20/11/2018 16:18, Jan Beulich wrote:
> >> For domain heap pages assigned to a domain dropping the page reference
> >> tied to PGC_allocated may not drop the last reference, as otherwise the
> >> test_a
>
> PG_balloon was introduced to implement page migration/compaction for pages
> inflated in virtio-balloon. Nowadays, it is only a marker that a page is
> part of virtio-balloon and therefore logically offline.
>
> We also want to make use of this flag in other balloon drivers - for
> inflated
On Tue, Nov 20, 2018 at 11:05 AM Razvan Cojocaru
wrote:
>
> Move p2m_mem_access_sanity_check() from the asm-x86/mem_access.h
> header, where it currently is declared inline, to
> arch/x86/mm/mem_access.c. This allows source code that includes it
> directly, or indirectly (such as xen/mem_access.h)
On Mon, Nov 19, 2018 at 11:16:11AM +0100, David Hildenbrand wrote:
> Right now, pages inflated as part of a balloon driver will be dumped
> by dump tools like makedumpfile. While XEN is able to check in the
> crash kernel whether a certain pfn is actuall backed by memory in the
> hypervisor (see xe
On Mon, Nov 19, 2018 at 11:16:10AM +0100, David Hildenbrand wrote:
> PG_balloon was introduced to implement page migration/compaction for pages
> inflated in virtio-balloon. Nowadays, it is only a marker that a page is
> part of virtio-balloon and therefore logically offline.
>
> We also want to m
On Mon, Nov 19, 2018 at 11:16:09AM +0100, David Hildenbrand wrote:
> Commit b1123ea6d3b3 ("mm: balloon: use general non-lru movable page
> feature") reworked balloon handling to make use of the general
> non-lru movable page feature. The big comment block in
> balloon_compaction.h contains quite so
> > >> ---
> > >> drivers/hv/hv_balloon.c | 14 --
> > >> 1 file changed, 12 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> > >> index 211f3fe3a038..47719862e57f 100644
> > >> --- a/drivers/hv/hv_balloon.c
> > >> +++ b/driv
flight 130629 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On Tue, Nov 20, 2018 at 09:45:13AM -0700, Jan Beulich wrote:
> >>> On 20.11.18 at 17:01, wrote:
> > Bridges are not behind an IOMMU, and are already special cased and
> > skipped in amd_iommu_add_device. Apply the same special casing when
> > updating page tables.
> >
> > This is required or else
flight 130599 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 19/11/18 19:14, Michael S. Tsirkin wrote:
> On Mon, Nov 19, 2018 at 06:14:26PM +0100, Paolo Bonzini wrote:
>> On 19/11/18 16:31, Igor Mammedov wrote:
>>> I've tried to give suggestions how to restructure series
>>> on per patch basis. In my opinion it quite possible to split
>>> series in severa
On 20/11/18 13:57, Igor Mammedov wrote:
> On Mon, 19 Nov 2018 18:14:26 +0100
> Paolo Bonzini wrote:
>
>> On 19/11/18 16:31, Igor Mammedov wrote:
>>> I've tried to give suggestions how to restructure series
>>> on per patch basis. In my opinion it quite possible to split
>>> series in several smal
flight 130625 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On Monday, November 19, 2018 11:16:15 AM CET David Hildenbrand wrote:
> Let's use pfn_to_online_page() instead of pfn_to_page() when checking
> for saveable pages to not save/restore offline memory sections.
>
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Len Brown
> Cc: Andrew Morton
> C
On Monday, November 19, 2018 11:16:16 AM CET David Hildenbrand wrote:
> The content of pages that are marked PG_offline is not of interest
> (e.g. inflated by a balloon driver), let's skip these pages.
>
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Len Brown
> Cc: Andrew Morton
> Cc: Mat
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid freebsd-install
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tr
flight 130580 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
On 11/20/18 17:33, Igor Mammedov wrote:
> On Wed, 7 Nov 2018 16:36:40 +0400
> Marc-André Lureau wrote:
>
>> Interfaces don't have instance, let's make the interface type really
>> abstract to avoid confusion.
>>
>> Signed-off-by: Marc-André Lureau
>> ---
>> include/hw/acpi/acpi_dev_interface.h
On 20/11/2018 18:10, Andrii Anisov wrote:
Hello Julien,
On 19.11.18 18:42, Julien Grall wrote:
There are no issue about processing IRQs before the syncs. It is the same as
if an IRQ was raised from ila different pCPUs.
So why do you need that?
From my understanding of gic-vgic code (old
flight 130617 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 hos
flight 130502 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Tue, Nov 20, 2018 at 05:35:54PM +, Andrew Cooper wrote:
> On 19/11/2018 21:31, Wei Liu wrote:
> > diff --git a/automation/scripts/build b/automation/scripts/build
> > index a1f9a5da56..d4aceb745f 100755
> > --- a/automation/scripts/build
> > +++ b/automation/scripts/build
> > @@ -28,6 +28,10
Hello Julien,
On 19.11.18 18:42, Julien Grall wrote:
There are no issue about processing IRQs before the syncs. It is the
same as if an IRQ was raised from ila different pCPUs.
So why do you need that?
From my understanding of gic-vgic code (old vgic), for the IRQs
targeting the `current` v
Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
xen-init-dom0 accept an extra argument for UUID.
Signed-off-by: Wei Liu
---
v3: new approach
---
tools/helpers/Makefile | 3 +-
tools/helpers/xen-init-dom0.c | 42 +
Move p2m_mem_access_sanity_check() from the asm-x86/mem_access.h
header, where it currently is declared inline, to
arch/x86/mm/mem_access.c. This allows source code that includes it
directly, or indirectly (such as xen/mem_access.h), to not worry
about also including sched.h for is_hvm_domain(). In
flight 130505 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Tue, Nov 20, 2018 at 05:33:24PM +0100, Igor Mammedov wrote:
> On Wed, 7 Nov 2018 16:36:40 +0400
> Marc-André Lureau wrote:
>
> > Interfaces don't have instance, let's make the interface type really
> > abstract to avoid confusion.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > includ
On 19/11/2018 21:31, Wei Liu wrote:
> diff --git a/automation/scripts/build b/automation/scripts/build
> index a1f9a5da56..d4aceb745f 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -28,6 +28,10 @@ make -j$(nproc) dist
>
> # Extract artifacts to avoid getting rewrit
>>> On 20.11.18 at 18:00, wrote:
> Now that idle scrub is the default option, all memory is marked as dirty
> and alloc_domheap_pages() will do eager scrubbing by default. This can
> lead to longer Dom0 construction and potentially to a watchdog timeout,
> especially on older H/W (e.g. Harpertown)
At 08:59 -0700 on 20 Nov (1542704343), Jan Beulich wrote:
> In particular sh_oos_audit() has become stale due to changes elsewhere,
> and the need for adjustment was not noticed because both "full audit"
> flags are off in both release and debug builds. Switch away from pre-
> processsor conditiona
On 20/11/2018 16:19, Jan Beulich wrote:
> Quite a bit of duplicate code has accumulated on the "paging" types
> special case path. Re-use what can be re-used from the common path.
>
> Since it needs touching anyway, slightly re-format and extend the
> gdprintk() on the common path as well.
>
> Sign
>>> On 20.11.18 at 17:59, wrote:
> On 20/11/2018 16:18, Jan Beulich wrote:
>> For domain heap pages assigned to a domain dropping the page reference
>> tied to PGC_allocated may not drop the last reference, as otherwise the
>> test_and_clear_bit() might already act on an unowned page.
>>
>> Work a
On 20/11/2018 16:18, Jan Beulich wrote:
> For domain heap pages assigned to a domain dropping the page reference
> tied to PGC_allocated may not drop the last reference, as otherwise the
> test_and_clear_bit() might already act on an unowned page.
>
> Work around this where possible, but the need t
Now that idle scrub is the default option, all memory is marked as dirty
and alloc_domheap_pages() will do eager scrubbing by default. This can
lead to longer Dom0 construction and potentially to a watchdog timeout,
especially on older H/W (e.g. Harpertown).
Pass MEMF_no_scrub to optimise this pro
On 20/11/2018 15:49, Jan Beulich wrote:
On 20.11.18 at 16:37, wrote:
>> To mitigate Meltdown, Xen has been fixed with a software fix, namely
>> using retpoline sequences generated by the compiler. This way, indirect
>> branches are protected against the attack.
> Actually I was meaning to com
On 20/11/2018 16:17, Jan Beulich wrote:
> When such pages get assigned to domains (and hence their ->tot_pages
> not incremented accordingly) we would otherwise also need to suppress
> decrementing the count when freeing those pages.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/page_alloc.c
On Tue, Nov 20, 2018 at 10:41:07AM -0600, Doug Goldstein wrote:
> On Mon, Nov 19, 2018 at 09:31:02PM +, Wei Liu wrote:
> > This patch introduces a new test stage into the pipeline and provides
> > a simple QEMU based smoke test.
> >
> > Signed-off-by: Wei Liu
> > ---
> > .gitlab-ci.yml
>>> On 20.11.18 at 17:01, wrote:
> Bridges are not behind an IOMMU, and are already special cased and
> skipped in amd_iommu_add_device. Apply the same special casing when
> updating page tables.
>
> This is required or else update_paging_mode will fail and return an
> error to the caller (amd_io
On 20/11/2018 15:59, Jan Beulich wrote:
> In particular sh_oos_audit() has become stale due to changes elsewhere,
> and the need for adjustment was not noticed because both "full audit"
> flags are off in both release and debug builds. Switch away from pre-
> processsor conditionals, thus exposing
On Mon, Nov 19, 2018 at 09:31:02PM +, Wei Liu wrote:
> This patch introduces a new test stage into the pipeline and provides
> a simple QEMU based smoke test.
>
> Signed-off-by: Wei Liu
> ---
> .gitlab-ci.yml | 19 +++
> automation/scripts/qemu-smoke-
On Wed, 7 Nov 2018 16:36:41 +0400
Marc-André Lureau wrote:
> Instead of accepting any Object*, change user_creatable_complete() to
> require a UserCreatable*. Modify the callers to pass the appropriate
> argument, removing redundant dynamic cast checks in object creation.
Looks like it doesn't
On Wed, 7 Nov 2018 16:36:43 +0400
Marc-André Lureau wrote:
> The function is only used by a test, move it there.
>
> Signed-off-by: Marc-André Lureau
> Reviewed-by: Eduardo Habkost
Reviewed-by: Igor Mammedov
> ---
> include/hw/qdev-properties.h | 1 -
> hw/core/qdev-properties.c |
On Mon, Nov 19, 2018 at 09:31:01PM +, Wei Liu wrote:
> ... so that it can be passed on to test stage.
>
> Note that xen is only extracted for x86_64 build since others may not
> have that. Use a directory to account for possibly different file
> names on Arm.
>
> Signed-off-by: Wei Liu
Acke
On Mon, Nov 19, 2018 at 09:31:00PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> .gitlab-ci.yml | 2 +-
> automation/scripts/build | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 5678b552c4..28152e906d 100644
On Mon, Nov 19, 2018 at 09:30:59PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> automation/build/README.md | 3 +++
> automation/scripts/containerize | 8 +---
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/automation/build/README.md b/automation/build/REA
On Wed, 7 Nov 2018 16:36:40 +0400
Marc-André Lureau wrote:
> Interfaces don't have instance, let's make the interface type really
> abstract to avoid confusion.
>
> Signed-off-by: Marc-André Lureau
> ---
> include/hw/acpi/acpi_dev_interface.h | 6 +-
> include/hw/arm/linux-boot-if.h
>>> On 20.11.18 at 15:37, wrote:
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
> presence of the MSR.
>
> Intr
>>> On 20.11.18 at 15:36, wrote:
> For more historical context, see
> c/s c17b36d5dc792cfdf59b6de0213b168bec0af8e8
> c/s 04656384a1b9714e43db850c51431008e23450d8
>
> PVRDTSCP was an attempt to provide Xen-aware userspace with a stable monotonic
> clock, and enough information for said userspa
>>> On 20.11.18 at 15:36, wrote:
> Currently, tsc_set_info() performs no parameter checking, and an invalid
> tsc_mode goes largely unnoticed. Fix it to reject invalid tsc_modes with
> -EINVAL, and update the callers to check the return value.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan
Even if unlikely, donate_page() should not ignore the possible need to
obtain a domain reference. To make people look more closely when they
add new uses of domain_adjust_tot_pages(), force its return value to be
checked. This in turn requires a benign change to assign_pages().
Signed-off-by: Jan
Quite a bit of duplicate code has accumulated on the "paging" types
special case path. Re-use what can be re-used from the common path.
Since it needs touching anyway, slightly re-format and extend the
gdprintk() on the common path as well.
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+
For domain heap pages assigned to a domain dropping the page reference
tied to PGC_allocated may not drop the last reference, as otherwise the
test_and_clear_bit() might already act on an unowned page.
Work around this where possible, but the need to acquire extra page
references is a fair hint th
When such pages get assigned to domains (and hence their ->tot_pages
not incremented accordingly) we would otherwise also need to suppress
decrementing the count when freeing those pages.
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2303,6 +2303,8 @@
Both our arm64 boxes are out of commission again.
I have filed a ticket to have the recently failed box investigated.
And I am working on the stretcb upgrade which will bring our
Thunder-X into service.
But for now this is the best we can do to unblock everything.
CC: Julien Grall
Signed-off-by
>>> On 20.11.18 at 16:57, wrote:
> On Tue, Nov 20, 2018 at 08:44:31AM -0700, Jan Beulich wrote:
>> >>> On 20.11.18 at 16:37, wrote:
>> > To mitigate Meltdown, Xen has been fixed with a software fix, namely
>> > using retpoline sequences generated by the compiler. This way, indirect
>> > branches
>>> On 20.11.18 at 17:01, wrote:
> AMD IOMMU devices are exposed on the PCI bus, and thus are assigned by
> default to the hardware domain. This can cause issues because the
> IOMMU devices themselves are not behind an IOMMU, so update_paging_mode will
> return an error if Xen tries to expand the
A few things I had run into while working on that issue:
1: mm: disallow MEMF_no_refcount to be passed for domain-owned allocations
2: x86: correct instances of PGC_allocated clearing
3: x86: reduce code duplication in guest_remove_page()
4: make domain_adjust_tot_pages() __must_check
They don't
On Tue, Nov 20, 2018 at 08:44:31AM -0700, Jan Beulich wrote:
> >>> On 20.11.18 at 16:37, wrote:
> > To mitigate Meltdown, Xen has been fixed with a software fix, namely
> > using retpoline sequences generated by the compiler. This way, indirect
> > branches are protected against the attack.
> >
>
When switching the memory decoding bit in the command register the
rest of the changes where dropped, leading to only the memory decoding
bit being updated.
Fix this by writing the command register once the guest physmap
manipulations are done if there are changes to the memory decoding
bit.
Note
Make sure the MSIX MMIO regions don't have p2m entries setup, so that
accesses to them trap into the hypervisor and can be handled by vpci.
Commit 042678762 ("x86/iommu: add map-reserved dom0-iommu option to
map reserved memory ranges") added mappings for all the reserved
regions into the PVH Dom0
AMD IOMMU devices are exposed on the PCI bus, and thus are assigned by
default to the hardware domain. This can cause issues because the
IOMMU devices themselves are not behind an IOMMU, so update_paging_mode will
return an error if Xen tries to expand the page tables of a domain
that has assigned
Hello,
The following series contain miscellaneous fixes for a PVH Dom0. I've
found out this issues while trying to boot on an AMD EPYC box.
The series can be found on my git repo:
git://xenbits.xen.org/people/royger/xen.git fixes-pvh-v5
Roger Pau Monne (6):
vpci: fix updating the command regi
Bridges are not behind an IOMMU, and are already special cased and
skipped in amd_iommu_add_device. Apply the same special casing when
updating page tables.
This is required or else update_paging_mode will fail and return an
error to the caller (amd_iommu_{un}map_page) which will destroy the
domai
Current logic to handle long running operations is flawed because it
doesn't prevent the guest vcpu from running. Fix this by raising a
scheduler softirq when preemption is required, so that the do_softirq
call in the guest entry path performs a rescheduling. Also move the
call to vpci_process_pend
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v4:
- New in this version.
---
xen/driver
In particular sh_oos_audit() has become stale due to changes elsewhere,
and the need for adjustment was not noticed because both "full audit"
flags are off in both release and debug builds. Switch away from pre-
processsor conditionals, thus exposing the code to the compiler at all
times. This obvi
flight 130607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130607/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
>>> On 20.11.18 at 16:37, wrote:
> To mitigate Meltdown, Xen has been fixed with a software fix, namely
> using retpoline sequences generated by the compiler. This way, indirect
> branches are protected against the attack.
Actually I was meaning to commit this right away, but then my
attention wa
>>> On 20.11.18 at 16:37, wrote:
> To mitigate Meltdown, Xen has been fixed with a software fix, namely
> using retpoline sequences generated by the compiler. This way, indirect
> branches are protected against the attack.
>
> However, the retpoline sequence comes with a slow down. To make up for
>>> On 20.11.18 at 16:30, wrote:
> Make X86_VENDOR_UNKNOWN have the value 0 so a piece of zeroed memory can't get
> confused with X86_VENDOR_INTEL.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mai
To mitigate Meltdown, Xen has been fixed with a software fix, namely
using retpoline sequences generated by the compiler. This way, indirect
branches are protected against the attack.
However, the retpoline sequence comes with a slow down. To make up for
this, we propose to avoid jump tables in th
On Wed, 7 Nov 2018 16:36:39 +0400
Marc-André Lureau wrote:
> Instead, it returns 1 if an error was detected, which is the case for:
>
> /qdev/properties/dynamic/global/subprocess:
> warning: global dynamic-prop-type-bad.prop3 has invalid class name
> warning: global nohotplug-type.prop5=105 not
Make X86_VENDOR_UNKNOWN have the value 0 so a piece of zeroed memory can't get
confused with X86_VENDOR_INTEL.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/x86-vendors.h | 12 ++--
1 file changed, 6 ins
Hello Julien,
It is me again.
On 15.11.18 17:05, Julien Grall wrote:
On 11/15/18 1:19 PM, Andrii Anisov wrote:
So I would prefer to stick with _t which is quite common within the p2m
code base so far.
I've found a similar code only in one place - p2m_get_entry()
function. And it is, at leas
>>> On 20.11.18 at 12:29, wrote:
> On 20/11/2018 11:06, Jan Beulich wrote:
> On 15.11.18 at 22:47, wrote:
>>> The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
>>> hardware which lacked the instruction. RDTSCP is available on almost all
>>> 64-bit x86 hardware.
>>>
>>> R
flight 130548 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130548/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 19 November 2018 at 12:08, Mao Zhongyi
wrote:
> Use DeviceClass rather than SysBusDeviceClass in
> xen_sysdev_class_init().
>
> Cc: sstabell...@kernel.org
> Cc: anthony.per...@citrix.com
> Cc: xen-devel@lists.xenproject.org
>
> Signed-off-by: Mao Zhongyi
> Signed-off-by: Zhang Shengju
> ---
>
On Mon, Nov 19, 2018 at 07:56:18AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > Make sure the MSIX MMIO regions don't have p2m entries setup, so that
> > accesses to them trap into the hypervisor and can be handled by vpci.
> >
> > Commit 042678762 ("x86/iommu: add map-reserve
On Tue, Nov 20, 2018 at 02:10:02PM +, Wei Liu wrote:
> They should have used .gcc-x86-32-build-debug in the first place.
>
> Signed-off-by: Wei Liu
> ---
> This patch is trivial so I intend to commit it as soon as possible to
> fix Gitlab CI.
Agreed.
Acked-by: Doug Goldstein
_
As noted in c/s 4999bf3e8b "x86/PV: use generic emulator for privileged
instruction handling", these hoops are jumped through to retain the older
behaviour, along with a note suggesting that we should reconsider things.
Part of the reason for retention of the old behaviour was removed by c/s
5b042
For more historical context, see
c/s c17b36d5dc792cfdf59b6de0213b168bec0af8e8
c/s 04656384a1b9714e43db850c51431008e23450d8
PVRDTSCP was an attempt to provide Xen-aware userspace with a stable monotonic
clock, and enough information for said userspace to cope with frequency
changes across migra
Boris has confirmed that noone appears to be using PVRDTSCP any more, and in
the decade since it was introduced, guest kernel / hardware support has
provided a better alternative.
For changes, see individual patches.
Andrew Cooper (5):
x86/time: Alter tsc_set_info() to return an error value
x
The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
hardware which lacked the instruction. RDTSCP is available on almost all
64-bit x86 hardware.
Remove this emulation, drop the TSC_MODE_PVRDTSCP constant, and allow RDTSCP
in a PV guest's CPUID policy.
Signed-off-by: Andrew Co
Currently, tsc_set_info() performs no parameter checking, and an invalid
tsc_mode goes largely unnoticed. Fix it to reject invalid tsc_modes with
-EINVAL, and update the callers to check the return value.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
*
With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
presence of the MSR.
Introduce cpu_has_rdpid along with the synthesized
Wei Liu writes ("[PATCH 3/3] xen-init-dom0: set Dom0 UUID if requested"):
> Read from XEN_CONFIG_DIR/dom0-uuid. If it contains a valid UUID, set
> it for Dom0.
I approve of the basic principle of this change. Thanks.
However, I am not particularly keen on the details of the config
representation
Wei Liu writes ("[PATCH 1/3] tools: update examples/README"):
> This file gets installed to the host system.
>
> This patch cleans it up: 1. remove things that don't exist anymore; 2.
> change xm to xl; 3. fix xen-devel list address; 4. add things that are
> missing.
Acked-by: Ian Jackson
_
Wei Liu writes ("[PATCH 2/3] tools/helpers: make gen_stub_json_config accept an
UUID argument"):
> If that's set, the stub is going to contain that UUID.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xen
On 20/11/2018 14:10, Wei Liu wrote:
> They should have used .gcc-x86-32-build-debug in the first place.
>
> Signed-off-by: Wei Liu
Oops yes - Acked-by: Andrew Cooper
> ---
> This patch is trivial so I intend to commit it as soon as possible to
> fix Gitlab CI.
> ---
> .gitlab-ci.yml | 4 ++--
>
They should have used .gcc-x86-32-build-debug in the first place.
Signed-off-by: Wei Liu
---
This patch is trivial so I intend to commit it as soon as possible to
fix Gitlab CI.
---
.gitlab-ci.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci
flight 130601 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130601/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
1 - 100 of 140 matches
Mail list logo
