During test, we found a crash on Xen with below trace.
(XEN) Xen call trace:
(XEN)[] R psr.c#l3_cdp_write_msr+0x1e/0x22
(XEN)[] F psr.c#do_write_psr_msrs+0x6d/0x109
(XEN)[] F smp_call_function_interrupt+0x5a/0xac
(XEN)[] F call_function_interrupt+0x20/0x34
(XEN)[] F do_IRQ+0x175
On 27.11.19 01:01, Julien Grall wrote:
Hi,
On 26/11/2019 23:17, Stefano Stabellini wrote:
On Tue, 26 Nov 2019, Julien Grall wrote:
Hi,
On 26/11/2019 20:43, Stefano Stabellini wrote:
+ Juergen
I missed that you weren't in CC to the original patch, sorry.
I think this patch should go in, as o
flight 144308 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 144299
Tests which di
On 26.11.19 18:30, George Dunlap wrote:
On 11/26/19 5:17 PM, George Dunlap wrote:
- xl will use the libxl default for maptrack, but does its own default
calculation for grant frames: either 32 or 64, based on the max
possible mfn.
[snip]
@@ -199,13 +198,6 @@ static void parse_global_co
On 26.11.19 18:17, George Dunlap wrote:
Xen used to have single, system-wide limits for the number of grant
frames and maptrack frames a guest was allowed to create. Increasing
or decreasing this single limit on the Xen command-line would change
the limit for all guests on the system.
Later, pe
On 26.11.19 18:08, Igor Druzhinin wrote:
IV bit shouldn't be set in DTE if interrupt remapping is not
enabled. It's a regression in behavior of "iommu=no-intremap"
option which otherwise would keep interrupt requests untranslated
for all of the devices in the system regardless of wether it's
desc
> From: Jan Beulich
> Sent: Wednesday, November 27, 2019 12:59 AM
>
> On 26.11.2019 17:47, Roger Pau Monné wrote:
> > On Tue, Nov 26, 2019 at 05:32:04PM +0100, Jan Beulich wrote:
> >> On 26.11.2019 14:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >>> +++ b/xen/arch/x86/hvm/
On Tue, Nov 26, 2019 at 03:41:53PM +, 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 an
> From: Roger Pau Monne
> Sent: Tuesday, November 26, 2019 9:27 PM
>
> 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 cal
> From: Roger Pau Monné
> Sent: Monday, November 18, 2019 10:56 PM
>
> On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> > On 18.11.2019 15:03, Roger Pau Monné wrote:
> > > On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
> > >> On 18.11.2019 11:16, Roger Pau Monne wrote
> From: Roger Pau Monné
> Sent: Thursday, November 21, 2019 5:26 PM
>
> On Mon, Nov 18, 2019 at 05:00:29PM +0100, Jan Beulich wrote:
> > On 18.11.2019 15:20, Roger Pau Monné wrote:
> > > On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote:
> > >> On 18.11.2019 14:46, Roger Pau Monné wro
On Tue, 26 Nov 2019, 23:18 Stefano Stabellini,
wrote:
> On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> > Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
> >
> > Use vcpu argument in vgic_connect_hw_irq.
> >
> > vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce wit
Hi,
On 26/11/2019 23:17, Stefano Stabellini wrote:
On Tue, 26 Nov 2019, Julien Grall wrote:
Hi,
On 26/11/2019 20:43, Stefano Stabellini wrote:
+ Juergen
I missed that you weren't in CC to the original patch, sorry.
I think this patch should go in, as otherwise Linux 5.4 could run into
proble
flight 144305 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144305/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144297
Tests which did not succee
On Tue, 26 Nov 2019, Julien Grall wrote:
> Hi,
>
> On 26/11/2019 20:43, Stefano Stabellini wrote:
> > + Juergen
> >
> > I missed that you weren't in CC to the original patch, sorry.
> > I think this patch should go in, as otherwise Linux 5.4 could run into
> > problems. It is also a pretty straig
On Mon, 25 Nov 2019, Julien Grall wrote:
> On 15/11/2019 20:14, Stewart Hildebrand wrote:
> > From: Ian Campbell
> >
> > ... instead of artificially masking the timer interrupt in the timer
> > state and relying on the guest to unmask (which it isn't required to
> > do per the h/w spec, although
On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> There are some IRQs that happen to have multiple "interrupts = < ... >;"
> properties with the same IRQ in the device tree. For example:
>
> interrupts = <0 123 4>,
> <0 123 4>,
> <0 123 4>,
> <0 123 4>,
>
On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
>
> Use vcpu argument in vgic_connect_hw_irq.
>
> vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with
> ASSERTs.
>
> Signed-off-by: Stewart Hildebrand
>
> ---
> v3
On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index f3f3fb7d7f..c3f4cd5069 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -34,6 +34,17 @@ enum domain_type {
> /* The hardware domain
On 26/11/2019 22:36, Stefano Stabellini wrote:
On Mon, 25 Nov 2019, Julien Grall wrote:
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_hw_irq.
vgic_
On Mon, 25 Nov 2019, Julien Grall wrote:
> 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_hw_irq.
> > >
> > > vgic_connect_hw
On Tue, Nov 26, 2019 at 1:20 PM Rich Persaud wrote:
>
> On Nov 26, 2019, at 15:23, Andrew Cooper wrote:
>
>
> On 26/11/2019 20:12, Roman Shaposhnik wrote:
>
> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
>
> wrote:
>
> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wr
On Nov 26, 2019, at 15:23, Andrew Cooper wrote:
> On 26/11/2019 20:12, Roman Shaposhnik wrote:
>>> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
>>> wrote:
>>> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
Hi Marek, after applying Jan's patch I'm making muc
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 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical
Hi,
On 26/11/2019 20:43, Stefano Stabellini wrote:
+ Juergen
I missed that you weren't in CC to the original patch, sorry.
I think this patch should go in, as otherwise Linux 5.4 could run into
problems. It is also a pretty straightforward 4 lines patch.
5.5 (or 5.6) is not going to run on Xe
On 11/26/2019 3:34 PM, Julien Grall wrote:
> Hi,
>
> On 26/11/2019 20:27, Jeff Kubascik wrote:
>> Add some background information on the BSP and instructions on how to
>> run the ticker application.
>>
>> Change-Id: I05050a335a938f00cc59bae69a014c5f04e05d23
>> ---
>> bsps/arm/xen/README | 130 ++
+ Juergen
I missed that you weren't in CC to the original patch, sorry.
I think this patch should go in, as otherwise Linux 5.4 could run into
problems. It is also a pretty straightforward 4 lines patch.
On Fri, 22 Nov 2019, Stefano Stabellini wrote:
> On Fri, 22 Nov 2019, Peng Fan wrote:
> > T
flight 144304 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144304/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144233
test-armhf-armhf-libvirt-raw 13 saveresto
Hi,
On 26/11/2019 20:27, Jeff Kubascik wrote:
Add some background information on the BSP and instructions on how to
run the ticker application.
Change-Id: I05050a335a938f00cc59bae69a014c5f04e05d23
---
bsps/arm/xen/README | 130 ++--
Hmmm what repo is i
flight 144301 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144301/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 144295
pass in 144301
test-amd64-amd64-
Add some background information on the BSP and instructions on how to
run the ticker application.
Change-Id: I05050a335a938f00cc59bae69a014c5f04e05d23
---
bsps/arm/xen/README | 130 ++--
1 file changed, 64 insertions(+), 66 deletions(-)
diff --git a/bsps/a
On 26/11/2019 20:12, Roman Shaposhnik wrote:
> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
> wrote:
>> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
>>> Hi Marek, after applying Jan's patch I'm making much further progress.
>>> Xen boots fine and Dom0 seems to b
On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
> > Hi Marek, after applying Jan's patch I'm making much further progress.
> > Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
> > my end).
It looks like gcc plays the usual dirty tricks with local variables renaming:
- xen-syms
7529: 82d0805fed50 8 OBJECT LOCAL DEFAULT 4230 lastpage.22857
- livepatch
289: 8 OBJECT GLOBAL DEFAULT UND hvm.c#lastpage.22856
Then, symbols resolution by name fails..
On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
> Hi Marek, after applying Jan's patch I'm making much further progress.
> Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
> my end).
>
> I'm attaching the logs from Xen and Dom0.
>
> At this point it seems tha
On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
> On 26.11.2019 14:26, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -515,7 +515,11 @@ void hvm_set_callback_via(struct domain *d, uint64_t
> > via)
> > struct hvm_intack hvm_vcpu_has_pe
Hi Marek, after applying Jan's patch I'm making much further progress.
Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
my end).
I'm attaching the logs from Xen and Dom0.
At this point it seems that adding efi=attr=uc is a better option for
these boxes than a wholesale efi=no-
flight 144310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144310/
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 20. Nov 2019, at 12:42, Sergey Dyasli wrote:
>
> On 19/11/2019 17:21, Wieczorkiewicz, Pawel wrote:
>>
>>
>>> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote:
>>>
>>> On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote:
Could you build the lp with debug (-d) and provide me with t
> -Original Message-
> From: Xen-devel On Behalf Of
> George Dunlap
> Sent: 26 November 2019 17:18
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Paul Durrant ; Andrew Cooper
> ; Konrad Rzeszutek Wilk
> ; George Dunlap ; Marek
>
George Dunlap writes ("[PATCH for-4.13 2/2] Rationalize max_grant_frames and
max_maptrack_frames handling"):
> Xen used to have single, system-wide limits for the number of grant
> frames and maptrack frames a guest was allowed to create. Increasing
> or decreasing this single limit on the Xen co
On 11/26/19 5:17 PM, George Dunlap wrote:
> - xl will use the libxl default for maptrack, but does its own default
> calculation for grant frames: either 32 or 64, based on the max
> possible mfn.
[snip]
> @@ -199,13 +198,6 @@ static void parse_global_config(const char *configfile,
>
>
On Tue, Nov 26, 2019 at 12:31 AM Jan Beulich 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 at
On Tue, Nov 26, 2019 at 1:51 AM Wei Liu wrote:
>
> 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: R
On 25/11/2019, 09:10, "Jan Beulich" wrote:
All,
the 4.12.2 stable release is due in about 2 weeks time. Please point
out backporting candidates that you find missing from the respective
stable trees.
Jan
Hi all:
I ran the XSA scripts and all is fine. BreaT
From: Julien Grall
A guest will setup a shared page with the hypervisor for each vCPU via
XENPMU_init. The page will then get mapped in the hypervisor and only
released when XEMPMU_finish is called.
This means that if the guest is not shutdown gracefully (such as via xl
destroy), the page will s
No functional change.
Signed-off-by: George Dunlap
---
CC: Marek Marczykowski-Górecki
CC: Juergen Gross
---
tools/python/xen/lowlevel/xc/xc.c | 210 +++---
1 file changed, 105 insertions(+), 105 deletions(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/pytho
Xen used to have single, system-wide limits for the number of grant
frames and maptrack frames a guest was allowed to create. Increasing
or decreasing this single limit on the Xen command-line would change
the limit for all guests on the system.
Later, per-domain limits for these values was creat
On 26/11/2019 17:08, Igor Druzhinin wrote:
> IV bit shouldn't be set in DTE if interrupt remapping is not
> enabled. It's a regression in behavior of "iommu=no-intremap"
> option which otherwise would keep interrupt requests untranslated
> for all of the devices in the system regardless of wether i
IV bit shouldn't be set in DTE if interrupt remapping is not
enabled. It's a regression in behavior of "iommu=no-intremap"
option which otherwise would keep interrupt requests untranslated
for all of the devices in the system regardless of wether it's
described as valid in IVRS or not.
Signed-off-
On 26.11.2019 17:47, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 05:32:04PM +0100, Jan Beulich wrote:
>> On 26.11.2019 14:26, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -2054,6 +2054,19 @@ static void vmx_sync_pir_to_irr(struct vcpu
On 26.11.2019 14:26, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -515,7 +515,11 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
> struct hvm_intack hvm_vcpu_has_pending_irq(struct vcpu *v)
> {
> struct hvm_domain *plat = &v->domain->
On Tue, Nov 26, 2019 at 05:32:04PM +0100, Jan Beulich wrote:
> On 26.11.2019 14:26, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2054,6 +2054,19 @@ static void vmx_sync_pir_to_irr(struct vcpu *v)
> > unsigned int group, i;
> > DE
On Tue, Nov 26, 2019 at 02:26:46PM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series aim to solve the issue reported by Joe Jin related
> to posted interrupts.
Regarding the release blockers email, and the qualification of this
series:
- a regression introduced since 4.12
This is
On 11/26/19 5:26 AM, Roger Pau Monne wrote:
> 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
On 26.11.2019 14:26, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2054,6 +2054,19 @@ static void vmx_sync_pir_to_irr(struct vcpu *v)
> unsigned int group, i;
> DECLARE_BITMAP(pending_intr, NR_VECTORS);
>
> +if ( v != current && !
Hello,
I am doing a bit of research on block tap, and I cannot find the source
code of a blktap driver module in the linux kernel.
I see in the linux tree some references to commits related to blktap,
but I am stuck with finding the actual code.
It would be really helpful to provide me som
George Dunlap writes ("[PATCH for-4.13 v2] docs/xl: Document pci-assignable
state"):
> 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
On 26/11/2019 16:14, Jan Beulich wrote:
> 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 b
In order to be able to release Xen 4.13 we need to get all regressions
fixed rather soon. I know there are quite some patches waiting to be
taken for 4.13.
So please, don't tag any further patches as "for 4.13" if they are not
fixing either:
- a regression introduced since 4.12
- a severe bug of
From: SeongJae Park
For each I/O request, blkback first maps the foreign pages for the
request to its local pages. If an allocation of a local page for the
mapping fails, it should unmap every mapping already made for the
request.
However, blkback's handling mechanism for the allocation failure
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
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 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: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: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: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
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 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
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.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
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.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
> -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
> -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: [
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 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 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
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
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,
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
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
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 =
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 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 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 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: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 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 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 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
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.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_
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 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
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 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.
>
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 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
1 - 100 of 161 matches
Mail list logo
