Commit 633a40947321 ("docs: Improve documentation and parsing for efi=")
failed to honor the strcmp()-like return value convention of
cmdline_strcmp().
Reported-by: Roman Shaposhnik
Signed-off-by: Jan Beulich
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1430,9 +1430,9 @@ static i
On 25.11.2019 18:49, Roger Pau Monné wrote:
> On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
>> On 25/11/2019 17:27, Roger Pau Monné wrote:
>>> On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
[...]
On 26.11.2019 08:02, Roman Shaposhnik wrote:
> On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
> wrote:
>> On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
>>> (XEN) 0ff90-0 type=11 attr=8000
>>> (XEN) Unknown cachability for MFNs 0xff90
On 25.11.2019 22:05, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1279,7 +1279,7 @@ static int __init amd_iommu_setup_device_table(
> for ( bdf = 0, size /= sizeof(*dt); bdf < size; ++bdf )
> dt[b
On 25.11.2019 18:37, Anthony PERARD wrote:
> On Mon, Nov 25, 2019 at 05:22:19PM +0100, Jan Beulich wrote:
>> On 25.11.2019 15:59, Anthony PERARD wrote:
>>> This hypercall can take a long time to finish because it attempts to
>>> grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
On Tue, Nov 26, 2019 at 09:30:47AM +0100, Jan Beulich wrote:
> On 25.11.2019 18:49, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
> >> On 25/11/2019 17:27, Roger Pau Monné wrote:
> >>> On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
> On Mo
On 26.11.19 10:08, Roger Pau Monné wrote:
On Tue, Nov 26, 2019 at 09:30:47AM +0100, Jan Beulich wrote:
On 25.11.2019 18:49, Roger Pau Monné wrote:
On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
On 25/11/2019 17:27, Roger Pau Monné wrote:
On Mon, Nov 25, 2019 at 05:07:04PM +00
On Tue, Nov 26, 2019 at 09:25:27AM +0100, Jan Beulich wrote:
> Commit 633a40947321 ("docs: Improve documentation and parsing for efi=")
> failed to honor the strcmp()-like return value convention of
> cmdline_strcmp().
>
> Reported-by: Roman Shaposhnik
> Signed-off-by: Jan Beulich
Reviewed-by:
On 26.11.19 09:25, Jan Beulich wrote:
Commit 633a40947321 ("docs: Improve documentation and parsing for efi=")
failed to honor the strcmp()-like return value convention of
cmdline_strcmp().
Reported-by: Roman Shaposhnik
Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
_
On Tue, Nov 26, 2019 at 09:25:27AM +0100, Jan Beulich wrote:
> Commit 633a40947321 ("docs: Improve documentation and parsing for efi=")
> failed to honor the strcmp()-like return value convention of
> cmdline_strcmp().
>
> Reported-by: Roman Shaposhnik
> Signed-off-by: Jan Beulich
Reviewed-by:
On 11/26/19 9:01 AM, Jan Beulich wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index a03e80e5984a..1b69eb75cb20 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -163,6 +163,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl
flight 144299 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144299/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144007
test-amd64-i386-xl-pvshim12
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
Main changes in v6:
- Added missing action pad field zeroing
Main changes in v4:
- Fix various typos and
This change is part of a independant stacked livepatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any livepatches built for different
hypervisor version as indicated by the Xen
Having detailed livepatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
livepatch loads in the system (at least within dmesg buffer size
limits).
The livepatch metadata are embedded in a form of .modinfo section.
Each such section c
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically supp
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure al
On 25.11.19 15:39, George Dunlap wrote:
On 11/25/19 1:49 PM, Jan Beulich wrote:
There are two mappings active in the middle of do_recalc(), and hence
commit 0d0f4d78e5d1 ("p2m: change write_p2m_entry to return an error
code") should have added (or otherwise invoked) unmapping code just
like it d
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent appl
By default Livepatch enforces the following buildid-based dependency
chain between livepatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper livepatch stack order is maintained and enforced.
While it i
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the livepatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a livepatch may be
constructed of only hooks to perf
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation require
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is
By default, in the quiescing zone, a livepatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
Extend the XC python bindings library to support also all common
livepatch operations and actions.
Add the python bindings for the following operations:
- status (pyxc_livepatch_status):
Requires a payload name as an input.
Returns a status dict containing a state string and a return code
in
This is the initial implementation of the expectations enhancement
to improve inline asm livepatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm livepatching. The flag enabled allows
to control the expectation state.
Each expectation has da
> On 25. Nov 2019, at 15:38, Ross Lagerwall wrote:
>
> On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
>> In the process of creating a final hotpatch module file make sure to
>> strip all transient symbols that have not been caught and removed by
>> create-diff-object processing. For now these
On 11/25/19 12:49 PM, Jan Beulich wrote:
> On 25.11.2019 13:39, George Dunlap wrote:
>> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
>> guests") attempted to "fake up" a topology which would induce guest
>> operating systems to not treat vcpus as sibling hyperthreads. Thi
On Wed, 13 Nov 2019 at 13:55, Paul Durrant wrote:
>
> ...when their values are larger than the per-domain configured limits.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc:
On 26.11.19 12:30, Paul Durrant wrote:
On Wed, 13 Nov 2019 at 13:55, Paul Durrant wrote:
...when their values are larger than the per-domain configured limits.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad
On 26/11/2019 11:30, Paul Durrant wrote:
> On Wed, 13 Nov 2019 at 13:55, Paul Durrant wrote:
>> ...when their values are larger than the per-domain configured limits.
>>
>> Signed-off-by: Paul Durrant
>> ---
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Ian Jackson
>> Cc: Jan Beulich
>> Cc
> -Original Message-
> From: Jürgen Groß
> Sent: 26 November 2019 11:37
> To: Paul Durrant ; Durrant, Paul
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Jan Beulich ; xen-devel
>
> Subject: Re: [Xen-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-306
version 2
Device quarantine for alternate pci assignment methods
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
The VT-x task switch handler adds inst_len to %rip before calling
hvm_task_switch(), which is problematic in two ways:
1) Early faults (i.e. ones delivered in the context of the old task) get
delivered with trap semantics, and break restartibility.
2) The addition isn't truncated to 32 bits
The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
assistance with instruction length. As a result, any instruction-induced task
switch has the outgoing task's %eip pointing at the instruction switch caused
the switch, rather than after it.
This causes callers of task gates
These patches want backporting due to the severity of patch 2. They should
therefore be considered for 4.13 at this point.
Andrew Cooper (3):
x86/vtx: Fix fault semantics for early task switch failures
x86/svm: Always intercept ICEBP
x86/svm: Write the correct %eip into the outgoing task
ICEBP isn't handled well by SVM.
The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
appropriate instruction boundary (fault or trap, as appropriate), except for
an ICEBP-induced #DB TASK_SWITCH, where %rip points at the ICEBP instruction
rather than after it. As ICEBP isn't
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
IMPROVEMENTS:
1. Strip redundant or transient symbols from resulting object files:
[6], [7]
This c
In the process of creating a final hotpatch module file make sure to
strip all transient symbols that have not been caught and removed by
create-diff-object processing. For now these are only the hooks
kpatch load/unload symbols.
For all new object files that are carried along for the final linkin
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
With stacked hotpatch modules it is essential that each and every
hotpatch is verified against the hypervisor bu
On 26/11/2019 08:42, Jan Beulich wrote:
> On 25.11.2019 22:05, Igor Druzhinin wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>> @@ -1279,7 +1279,7 @@ static int __init amd_iommu_setup_device_table(
>> for ( bdf = 0, size /= sizeof
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-byte alignment padding to reserve
place for future flags and options.
The new fields are zero-out upon .livepatch.funcs section creation.
Include new sections containing optional pre-, post- action hooks.
The following new section names are supported:
- .livepatch.hooks.preapply
- .livepatch.hooks.postapply
- .livepatch.hooks.prerevert
- .livepatch.hooks.postrevert
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Ross Lage
Include new sections containing optional apply and revert action
hooks.
The following new section names are supported:
- .livepatch.hooks.apply
- .livepatch.hooks.revert
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Ross Lagerwall
---
create-diff-object.c | 10 ++
1 file changed
Extend livepatch_patch_func to support a new field: expect. This new
field describes the expected data, its length and whether expectation
is enabled. The expectation's data is of opaque padding size.
By default the expectation field is zero-out and the expectation is
disabled unless explicitly sp
Strip all unneeded metadata symbols from generated hotpatch modules.
The metadata symbols are the symbols from metadata-like sections (e.g.
'.livepatch.funcs') or livepatch hooks symbols (defined by a set of
prefixes. E.g. 'livepatch_load_data_').
By default the create-diff-object does not create
On 26.11.2019 14:03, Andrew Cooper wrote:
> ICEBP isn't handled well by SVM.
>
> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
> appropriate instruction boundary (fault or trap, as appropriate), except for
> an ICEBP-induced #DB TASK_SWITCH, where %rip points at the IC
This seems required by the Xen repo's add_maintainers.pl script.
Signed-off-by: Pawel Wieczorkiewicz
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index de2aedb..aa04d06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9,3 +9,4 @@ L: xen-devel@l
On 11/26/19 11:30 AM, Paul Durrant wrote:
> On Wed, 13 Nov 2019 at 13:55, Paul Durrant wrote:
>>
>> ...when their values are larger than the per-domain configured limits.
>>
>> Signed-off-by: Paul Durrant
>> ---
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Ian Jackson
>> Cc: Jan Beulich
>
On 25.11.19 17:22, Jan Beulich wrote:
On 25.11.2019 15:59, Anthony PERARD wrote:
This hypercall can take a long time to finish because it attempts to
grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
lock can take several seconds.
This can easily happen with a guest with 32
On 26.11.2019 13:30, Pawel Wieczorkiewicz wrote:
> This seems required by the Xen repo's add_maintainers.pl script.
>
> Signed-off-by: Pawel Wieczorkiewicz
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de2aedb..aa04d06 100644
> --
The livepatch-build-tools MAINTAINERS file is missing V: version
identifier. This seems required by the Xen repo's add_maintainers.pl
script.
Signed-off-by: Pawel Wieczorkiewicz
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index de2aedb..aa04d06 1
> -Original Message-
> From: George Dunlap
> Sent: 26 November 2019 12:32
> To: Paul Durrant ; Durrant, Paul
> Cc: xen-devel ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap ; Andrew Cooper
> ; Ian Jackson ; Jan
> Beulich
> Subject: Re: [Xen-dev
... if the vCPU is different than the one currently running or if it's
not paused. Note that syncing PIR to IRR when the vCPU is running is
not allowed, since the hardware is in control of VMCS IRR field.
Allow syncing PIR to IRR when the vCPU is paused, this is required in
order to save the local
When using posted interrupts on Intel hardware it's possible that the
vCPU resumes execution with a stale local APIC IRR register because
depending on the interrupts to be injected vlapic_has_pending_irq
might not be called, and thus PIR won't be synced into IRR.
Fix this by making sure PIR is alw
Hello,
The following series aim to solve the issue reported by Joe Jin related
to posted interrupts.
I've decided to send a new version because the previous one was missing
the first patch, and I've also taken the opportunity to address Jan's
comments related to patch 2. It's still missing feedba
Commit d661611d08 "docs/markdown: Switch to using pandoc, and fix
underscore escaping" converted the livepatch documentation from markdown
to pandoc.
Update MAINTAINERS to reflect the change so the correct maintainers are
CCed to the patches.
Fixes: d661611d08 ("docs/markdown: Switch to using pan
On 11/25/2019 5:17 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 20:58, Jeff Kubascik wrote:
>> The tx/rx fifo flags were not set when the vpl011 is initialized. This
>> is a problem for certain guests that are operating in polled mode, as a
>> guest will generally check the rx fifo empty flag t
Kees Cook mentioned that it is a good idea to assert the PAN state
during disable/enable. Since, with this change everything is moved to
the same C place, if this hardening is something others also want to
see, I could add it in the next revision of this series. Here are the
options to choose from:
Hi,
On 26/11/2019 01:20, Stefano Stabellini wrote:
On Mon, 25 Nov 2019, Julien Grall wrote:
(+ Andre)
On 23/11/2019 20:35, Julien Grall wrote:
Hi,
On 15/11/2019 20:10, Stewart Hildebrand wrote:
Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
Use vcpu argument in vgic_connect_
On 25/11/2019 15:42, Jan Beulich wrote:
> On 25.11.2019 15:21, Sander Eikelenboom wrote:
>> L.S.,
>>
>> At present one of my PVH VM's kernel crashed with the splat below
>> (haven't seen it before, so could be something that happens sporadically).
>>
>> Any ideas ?
>>
>> --
>> Sander
>>
>>
>>
>> da
On 11/26/19 1:26 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: George Dunlap
>> Sent: 26 November 2019 12:32
>> To: Paul Durrant ; Durrant, Paul
>> Cc: xen-devel ; Stefano Stabellini
>> ; Julien Grall ; Wei Liu
>> ; Konrad Rzeszutek Wilk ; George
>> Dunlap ; Andrew Cooper
>> ; I
flight 144300 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144300/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
On 26.11.2019 14:30, Julien Grall wrote:
> Commit d661611d08 "docs/markdown: Switch to using pandoc, and fix
> underscore escaping" converted the livepatch documentation from markdown
> to pandoc.
>
> Update MAINTAINERS to reflect the change so the correct maintainers are
> CCed to the patches.
>
Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
introduced PCI device "quarantine" behavior, but did not document how
the pci-assignable-add and -remove functions act in regard to this.
Rectify this.
Signed-off-by:
On Tue, Nov 26, 2019 at 02:10:26PM +, George Dunlap wrote:
> Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> introduced PCI device "quarantine" behavior, but did not document how
> the pci-assignable-add and
George Dunlap writes ("[PATCH for-4.13] docs/xl: Document pci-assignable
state"):
> =item B [I<-r>] I
...
> +Make the device at PCI Bus/Device/Function BDF not assignable to
> +guests. This will at least unbind the device from pciback, and
> +re-assign it from the "quarantine domain" back to dom
On 26.11.2019 13:25, Andrew Cooper wrote:
> On 26/11/2019 08:42, Jan Beulich wrote:
>> On 25.11.2019 22:05, Igor Druzhinin wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>>> @@ -1279,7 +1279,7 @@ static int __init amd_iommu_setup_device_
flight 144307 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144307/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 26.11.19 15:10, George Dunlap wrote:
Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
introduced PCI device "quarantine" behavior, but did not document how
the pci-assignable-add and -remove functions act in rega
On 26/11/2019 14:14, Jan Beulich wrote:
> On 26.11.2019 13:25, Andrew Cooper wrote:
>> On 26/11/2019 08:42, Jan Beulich wrote:
>>> On 25.11.2019 22:05, Igor Druzhinin wrote:
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1279,7 +1279
On 11/26/19 2:14 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH for-4.13] docs/xl: Document pci-assignable
> state"):
>> =item B [I<-r>] I
> ...
>> +Make the device at PCI Bus/Device/Function BDF not assignable to
>> +guests. This will at least unbind the device from pciback, and
>> +re-
On 26.11.2019 15:14, Ian Jackson wrote:
> George Dunlap writes ("[PATCH for-4.13] docs/xl: Document pci-assignable
> state"):
>> =item B [I<-r>] I
> ...
>> +Make the device at PCI Bus/Device/Function BDF not assignable to
>> +guests. This will at least unbind the device from pciback, and
>> +re-
On 11/26/19 1:11 PM, Pawel Wieczorkiewicz wrote:
> The livepatch-build-tools MAINTAINERS file is missing V: version
> identifier. This seems required by the Xen repo's add_maintainers.pl
> script.
>
> Signed-off-by: Pawel Wieczorkiewicz
> ---
Acked-by: Ross Lagerwall
__
On 26.11.2019 15:24, Igor Druzhinin wrote:
> On 26/11/2019 14:14, Jan Beulich wrote:
>> On 26.11.2019 13:25, Andrew Cooper wrote:
>>> On 26/11/2019 08:42, Jan Beulich wrote:
On 25.11.2019 22:05, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/
On 11/26/19 12:25 PM, Pawel Wieczorkiewicz wrote:
> In the process of creating a final hotpatch module file make sure to
> strip all transient symbols that have not been caught and removed by
> create-diff-object processing. For now these are only the hooks
> kpatch load/unload symbols.
>
> For al
On 26/11/2019 14:14, Jan Beulich wrote:
> On 26.11.2019 13:25, Andrew Cooper wrote:
>> On 26/11/2019 08:42, Jan Beulich wrote:
>>> On 25.11.2019 22:05, Igor Druzhinin wrote:
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1279,7 +1279
Print the PCI coordinates in its common format and use d%u notation for the
domain. As well as printing flags, decode them. IO_PAGE_FAULT is used for
interrupt remapping errors as well as DMA remapping errors.
Before:
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0xa1, fault address =
RFC for-4.13. These are diagnostic improvements/corrections, so are low risk
and high utility.
Andrew Cooper (2):
AMD/IOMMU: Always print IOMMU errors
AMD/IOMMU: Render IO_PAGE_FAULT errors in a more useful manner
xen/drivers/passthrough/amd/iommu_init.c | 48 +++---
Unhandled IOMMU errors (i.e. not IO_PAGE_FAULT) should still be printed, and
not hidden behind iommu=debug.
While adjusting this, factor out the symbolic name handling to just one
location exposing its off-by-one nature.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
---
x
George Dunlap writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable
state"):
> I kind of feel like the discussion of the security risks inherent in pci
> passthrough belong in a separate document, but perhaps a brief mention
> here would be helpful. Perhaps the following?
>
> "As always
Ian Jackson writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable
state"):
> George Dunlap writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable
> state"):
> > I kind of feel like the discussion of the security risks inherent in pci
> > passthrough belong in a separate document,
On Tue, 2019-11-26 at 12:03 +, Andrew Cooper wrote:
> ICEBP isn't handled well by SVM.
>
> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to
> the
> appropriate instruction boundary (fault or trap, as appropriate),
> except for
> an ICEBP-induced #DB TASK_SWITCH, where %rip
On 26.11.2019 15:34, Andrew Cooper wrote:
> On 26/11/2019 14:14, Jan Beulich wrote:
>> On 26.11.2019 13:25, Andrew Cooper wrote:
>>> On 26/11/2019 08:42, Jan Beulich wrote:
On 25.11.2019 22:05, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/p
> -Original Message-
> From: Ian Jackson
> Sent: 26 November 2019 14:22
> To: George Dunlap
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Jan Beulich
> ; Paul Durrant ; Juergen Gross
>
> Subject: Re: [PATCH for-4.13] docs/xl: Document pci-assignable state
>
> [resending to just Paul t
On 11/25/2019 5:07 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 16:14, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the ARMv8 Arch Reference Manual, the o
> -Original Message-
> From: Ian Jackson
> Sent: 26 November 2019 15:06
> To: George Dunlap ; xen-
> de...@lists.xenproject.org; Wei Liu ; Jan Beulich
> ; Durrant, Paul ; Juergen Gross
>
> Subject: Re: [PATCH for-4.13] docs/xl: Document pci-assignable state
>
> Ian Jackson writes ("Re: [
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 26 November 2019 14:27
> To: Ian Jackson
> Cc: Juergen Gross ; xen-devel@lists.xenproject.org; Paul
> Durrant ; George Dunlap
> ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH for-4.13] docs/xl: Document pci-assignable
On 26.11.2019 13:03, Andrew Cooper wrote:
> ICEBP isn't handled well by SVM.
>
> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
> appropriate instruction boundary (fault or trap, as appropriate), except for
> an ICEBP-induced #DB TASK_SWITCH, where %rip points at the ICEB
On Tue, Nov 26, 2019 at 12:03:56PM +, Andrew Cooper wrote:
> ICEBP isn't handled well by SVM.
>
> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
> appropriate instruction boundary (fault or trap, as appropriate), except for
> an ICEBP-induced #DB TASK_SWITCH, where %r
On 26.11.19 16:01, Andrew Cooper wrote:
RFC for-4.13. These are diagnostic improvements/corrections, so are low risk
and high utility.
Sorry, but the release is at least 1 month late now. As said before:
I'll only take real bug fixes now.
Juergen
Currently if a user tries to live-load the same or older ucode revision
than CPU already has, he will get a single message in Xen log like:
(XEN) 128 cores are to update their microcode
No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode u
On 26.11.2019 13:03, Andrew Cooper wrote:
> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
> assistance with instruction length. As a result, any instruction-induced task
> switch has the outgoing task's %eip pointing at the instruction switch caused
> the switch, rather
Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
introduced PCI device "quarantine" behavior, but did not document how
the pci-assignable-add and -remove functions act in regard to this.
Rectify this.
Signed-off-by:
On 26.11.2019 16:41, Sergey Dyasli wrote:
> Currently if a user tries to live-load the same or older ucode revision
> than CPU already has, he will get a single message in Xen log like:
>
> (XEN) 128 cores are to update their microcode
>
> No actual ucode loading will happen and this situatio
On 26/11/2019 15:32, Jan Beulich wrote:
> On 26.11.2019 13:03, Andrew Cooper wrote:
>> ICEBP isn't handled well by SVM.
>>
>> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
>> appropriate instruction boundary (fault or trap, as appropriate), except for
>> an ICEBP-induced
On 26.11.2019 16:59, Andrew Cooper wrote:
> On 26/11/2019 15:32, Jan Beulich wrote:
>> On 26.11.2019 13:03, Andrew Cooper wrote:
>>> ICEBP isn't handled well by SVM.
>>>
>>> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
>>> appropriate instruction boundary (fault or trap,
On 26/11/2019 15:34, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 12:03:56PM +, Andrew Cooper wrote:
>> ICEBP isn't handled well by SVM.
>>
>> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
>> appropriate instruction boundary (fault or trap, as appropriate), except
On 26/11/2019 16:05, Jan Beulich wrote:
> On 26.11.2019 16:59, Andrew Cooper wrote:
>> On 26/11/2019 15:32, Jan Beulich wrote:
>>> On 26.11.2019 13:03, Andrew Cooper wrote:
ICEBP isn't handled well by SVM.
The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
On 26.11.2019 17:11, Andrew Cooper wrote:
> On 26/11/2019 16:05, Jan Beulich wrote:
>> On 26.11.2019 16:59, Andrew Cooper wrote:
>>> On 26/11/2019 15:32, Jan Beulich wrote:
On 26.11.2019 13:03, Andrew Cooper wrote:
> ICEBP isn't handled well by SVM.
>
> The VMexit state for a #DB-v
1 - 100 of 161 matches
Mail list logo
