On 14.03.2023 11:24, Jan Beulich wrote:
> On 14.03.2023 02:50, Tian, Kevin wrote:
>>> From: Marek Marczykowski-Górecki
>>> Sent: Tuesday, March 14, 2023 9:32 AM
>>>
>>> If the scope for IGD's IOMMU contains additional device that doesn't
>>>
On 14.03.2023 02:50, Tian, Kevin wrote:
>> From: Marek Marczykowski-Górecki
>> Sent: Tuesday, March 14, 2023 9:32 AM
>>
>> If the scope for IGD's IOMMU contains additional device that doesn't
>> actually exist, iommu=no-igfx would not disable that IOMMU. In this
>
> From: Marek Marczykowski-Górecki
> Sent: Tuesday, March 14, 2023 9:32 AM
>
> If the scope for IGD's IOMMU contains additional device that doesn't
> actually exist, iommu=no-igfx would not disable that IOMMU. In this
> particular case (Thinkpad x230) it
If the scope for IGD's IOMMU contains additional device that doesn't
actually exist, iommu=no-igfx would not disable that IOMMU. In this
particular case (Thinkpad x230) it included
00:02.1, but there is no such device on this platform.
Consider only existing devices for "gfx only" che
On 26.02.2023 01:08, Marek Marczykowski-Górecki wrote:
> If the scope for IGD's IOMMU contains additional device that doesn't
> actually exist, iommu=no-igfx would not disable that IOMMU. In this
> particular case (Thinkpad x230) it included
> 00:02.1, but there is no such device on t
If the scope for IGD's IOMMU contains additional device that doesn't
actually exist, iommu=no-igfx would not disable that IOMMU. In this
particular case (Thinkpad x230) it included
00:02.1, but there is no such device on this platform.
Consider only existing devices for "gfx only" chec
> From: Jan Beulich
> Sent: Monday, October 11, 2021 4:49 PM
>
> Linux'es supposedly equivalent "intel_iommu=igfx_off" deals with any
> graphics devices (not just Intel ones) while at the same time limiting
> the effect to IOMMUs covering only graphics devices. Keying the decision
> to leave
Linux'es supposedly equivalent "intel_iommu=igfx_off" deals with any
graphics devices (not just Intel ones) while at the same time limiting
the effect to IOMMUs covering only graphics devices. Keying the decision
to leave translation disabled for an IOMMU to merely a magic SBDF tuple
was wrong in
On Thu, May 28, 2020 at 11:34 AM Tian, Kevin wrote:
> You may search dma_map* in drivers/gpu/drm/i915, and then print mapped
> addresses to see any match in VT-d reported faulting addresses. For
> example, __setup_page_dma might be one example that you want to check.
>
Unfortunately, I'm not
@lists.xenproject.org
Subject: Re: iommu=no-igfx
On Mon, May 25, 2020 at 5:16 AM Tian, Kevin
mailto:kevin.t...@intel.com>> wrote:
> From: Jan Beulich mailto:jbeul...@suse.com>>
> Sent: Wednesday, May 20, 2020 7:11 PM
>
> On 11.05.2020 19:43, buy computer wrote:
> > I'v
; > > trying to make the VM, I was getting IOMMU errors. I had a hard time
> > > figuring out what to do about this, and finally discovered that putting
> > > iommu=no-igfx in the grub stopped the errors.
> > >
> > > Unfortunately, without the graphics support
gt; figuring out what to do about this, and finally discovered that putting
> > iommu=no-igfx in the grub stopped the errors.
> >
> > Unfortunately, without the graphics support the VM is understandably
> slow,
> > and can crash. I was also only now pointed to the page
On 11.05.2020 19:43, buy computer wrote:
> I've been working on a Windows 10 HVM on a Debian 10 dom0. When I was first
> trying to make the VM, I was getting IOMMU errors. I had a hard time
> figuring out what to do about this, and finally discovered that putting
> iommu=no-igfx
Hi!
I've been working on a Windows 10 HVM on a Debian 10 dom0. When I was first
trying to make the VM, I was getting IOMMU errors. I had a hard time
figuring out what to do about this, and finally discovered that putting
iommu=no-igfx in the grub stopped the errors.
Unfortunately, without
On Mon, Aug 19, 2019 at 1:16 AM Roger Pau Monné wrote:
>
> On Sun, Aug 18, 2019 at 10:00:17PM -0700, Roman Shaposhnik wrote:
> > Hi Roger!
> >
> > Some good news, some bad news ;-)
> >
> > Good news is that on the newer BIOS, your original patch seems to work fine.
> >
> > IOW, with newer BIOS:
>
On Sun, Aug 18, 2019 at 10:00:17PM -0700, Roman Shaposhnik wrote:
> Hi Roger!
>
> Some good news, some bad news ;-)
>
> Good news is that on the newer BIOS, your original patch seems to work fine.
>
> IOW, with newer BIOS:
> 1. without your original patch I see garbled screen
> 2. with
Hi Roger!
Some good news, some bad news ;-)
Good news is that on the newer BIOS, your original patch seems to work fine.
IOW, with newer BIOS:
1. without your original patch I see garbled screen
2. with your original patch everything boots normally.
Bad news is that with older BIOS,
On Tue, Aug 13, 2019 at 12:24:32PM -0700, Roman Shaposhnik wrote:
> Hi Roger,
>
> sorry for the delay -- I hope you will understand that I actually had
> a good reason. See below:
No problem, just wanted to make sure this doesn't fell through the
cracks.
> On Mon, Aug 12, 2019 at 1:57 AM Roger
Hi Roger,
sorry for the delay -- I hope you will understand that I actually had
a good reason. See below:
On Mon, Aug 12, 2019 at 1:57 AM Roger Pau Monné wrote:
>
> Ping?
>
> I know I've posted this quite recently, but have you been able to test
> the two proposed patches?
>
> ie: the one here
Ping?
I know I've posted this quite recently, but have you been able to test
the two proposed patches?
ie: the one here and:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00643.html
I would like to figure out exactly what's going on and fix this
properly.
Thanks, Roger.
On
On Wed, Aug 07, 2019 at 10:31:40AM +0200, Jan Beulich wrote:
> On 07.08.2019 09:35, Roger Pau Monné wrote:
> > On Tue, Aug 06, 2019 at 02:48:51PM -0700, Roman Shaposhnik wrote:
> > > On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Fri, Aug 02, 2019 at 10:05:40AM
On 07.08.2019 11:57, Roger Pau Monné wrote:
On Wed, Aug 07, 2019 at 09:08:58AM +0200, Jan Beulich wrote:
On 06.08.2019 23:48, Roman Shaposhnik wrote:
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
On Thu, Aug 01, 2019
On Wed, Aug 07, 2019 at 09:08:58AM +0200, Jan Beulich wrote:
> On 06.08.2019 23:48, Roman Shaposhnik wrote:
> > On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
> > >
> > > On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > > > On Thu, Aug 01, 2019 at 11:25:04AM -0700,
On 07.08.2019 09:35, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 02:48:51PM -0700, Roman Shaposhnik wrote:
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik
On Tue, Aug 06, 2019 at 02:48:51PM -0700, Roman Shaposhnik wrote:
> On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
> >
> > On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > > On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > > > This patch completely
On 06.08.2019 23:48, Roman Shaposhnik wrote:
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
This patch completely fixes the problem for me!
Thanks
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
>
> On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > > This patch completely fixes the problem for me!
> > >
> > > Thanks Roger! I'd love to see this in
On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> On Thu, Aug 1, 2019 at 1:16 AM Roger Pau Monné wrote:
> >
> > On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote:
> > > On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper
> > > wrote:
> > > >
> > > > On 31/07/2019
On Thu, Aug 1, 2019 at 1:16 AM Roger Pau Monné wrote:
>
> On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote:
> > On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper
> > wrote:
> > >
> > > On 31/07/2019 20:35, Roman Shaposhnik wrote:
> > > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau
On Thu, Aug 1, 2019 at 1:45 AM Roger Pau Monné wrote:
>
> On Wed, Jul 31, 2019 at 12:30:04PM -0700, Roman Shaposhnik wrote:
> > On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> > > > Sorry -- got a bit
On Wed, Jul 31, 2019 at 12:30:04PM -0700, Roman Shaposhnik wrote:
> On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné wrote:
> >
> > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> > > Sorry -- got a bit distracted yesterday. Attached is the log with only
> > > your latest patch
On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote:
> On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper
> wrote:
> >
> > On 31/07/2019 20:35, Roman Shaposhnik wrote:
> > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné
> > > wrote:
> > >> On Wed, Jul 31, 2019 at 10:36:31AM +0200,
On 31.07.2019 21:46, Andrew Cooper wrote:
> My bet is on the intel_iommu_lookup_page() call having side effects[1].
> If you take out the debugging in the middle of the loop in
> rmrr_identity_mapping(), does the problem reproduce again?
While your guess was right according to Roman's latest
On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper
wrote:
>
> On 31/07/2019 20:35, Roman Shaposhnik wrote:
> > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné
> > wrote:
> >> On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote:
> >>> On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman
On 31/07/2019 20:35, Roman Shaposhnik wrote:
> On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné wrote:
>> On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote:
>>> On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
Sorry -- got a bit distracted yesterday. Attached is
On Wed, Jul 31, 2019 at 2:46 AM Jan Beulich wrote:
>
> On 31.07.2019 10:58, Andrew Cooper wrote:
> > On 31/07/2019 09:34, Jan Beulich wrote:
> >> On 30.07.2019 19:56, Roman Shaposhnik wrote:
> >>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
> On 23.07.2019 20:25, Roman Shaposhnik
On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné wrote:
>
> On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote:
> > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> > > Sorry -- got a bit distracted yesterday. Attached is the log with only
> > > your latest patch
On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné wrote:
>
> On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> > Sorry -- got a bit distracted yesterday. Attached is the log with only
> > your latest patch attached. Interestingly enough the box booted fine
> > without screen
On 31.07.2019 10:58, Andrew Cooper wrote:
> On 31/07/2019 09:34, Jan Beulich wrote:
>> On 30.07.2019 19:56, Roman Shaposhnik wrote:
>>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
On 23.07.2019 20:25, Roman Shaposhnik wrote:
> Interestingly enough, adding iommu_inclusive_mapping=1
On 31/07/2019 09:34, Jan Beulich wrote:
> On 30.07.2019 19:56, Roman Shaposhnik wrote:
>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
>>> On 23.07.2019 20:25, Roman Shaposhnik wrote:
Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
booted the system just
On 30.07.2019 19:56, Roman Shaposhnik wrote:
> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
>>
>> On 23.07.2019 20:25, Roman Shaposhnik wrote:
>>> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
>>> booted the system just fine.
>>
>> Btw (I've noticed this only now) -
On 30.07.2019 19:55, Roman Shaposhnik wrote:
> Sorry -- got a bit distracted yesterday. Attached is the log with only
> your latest patch attached. Interestingly enough the box booted fine
> without screen artifacts. So I guess we're getting closer...
I'm afraid I can't make sense of this and the
On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote:
> On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> > Sorry -- got a bit distracted yesterday. Attached is the log with only
> > your latest patch attached. Interestingly enough the box booted fine
> > without
On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote:
> Sorry -- got a bit distracted yesterday. Attached is the log with only
> your latest patch attached. Interestingly enough the box booted fine
> without screen artifacts. So I guess we're getting closer...
>
> Thanks for all the
On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
>
> On 23.07.2019 20:25, Roman Shaposhnik wrote:
> > Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
> > booted the system just fine.
>
> Btw (I've noticed this only now) - are you saying without "iommu=debug"
> the box
Ping?
It would be very helpful for us in order to get this sorted out if you
could answer the questions below and try the new debug patch :).
On Fri, Jul 26, 2019 at 11:35:45AM +0200, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 05:47:19PM -0700, Roman Shaposhnik wrote:
> > Hi Roger!
> >
>
On Thu, Jul 25, 2019 at 05:47:19PM -0700, Roman Shaposhnik wrote:
> Hi Roger!
>
> With your patch (and build as a debug build) Xen crashes on boot
> (which I guess was the point of your BUG_ON statement).
Yes, that's very weird, seems like entries are not added to the iommu
page tables but I
On 23.07.2019 20:25, Roman Shaposhnik wrote:
> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
> booted the system just fine.
Btw (I've noticed this only now) - are you saying without "iommu=debug"
the box does _not_ boot fine, despite the other option?
Jan
On Wed, Jul 24, 2019 at 10:42 AM Rich Persaud wrote:
>
> On Jul 19, 2019, at 15:31, Roman Shaposhnik wrote:
>
> Hi!
>
> we're using Xen on Advantech ARK-2250 Embedded Box PC:
>
> https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
>
Hi Roger!
With your patch (and build as a debug build) Xen crashes on boot
(which I guess was the point of your BUG_ON statement).
The log is attached
Thanks,
Roman.
On Wed, Jul 24, 2019 at 7:11 AM Roger Pau Monné wrote:
>
> On Tue, Jul 23, 2019 at 10:32:26AM -0700, Roman Shaposhnik wrote:
>
> On Jul 19, 2019, at 15:31, Roman Shaposhnik wrote:
>
> Hi!
>
> we're using Xen on Advantech ARK-2250 Embedded Box PC:
>
> https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
Roman,
Good to see Xen being used on fanless
On Tue, Jul 23, 2019 at 10:32:26AM -0700, Roman Shaposhnik wrote:
> Hi Roger!
>
> I applied your patch, removed no-igfx and I still see the original
> problem. Please let me know what other logs/debugs would you need at
> this point.
I'm not sure why you don't get the rmrrs added to the iommu
On 24.07.2019 14:00, Jan Beulich wrote:
> On 23.07.2019 19:58, Roman Shaposhnik wrote:
>> No worries. Take a look at the head of the log attached.
>
> One more thing for you to tweak to make the log even more useful:
> As per
>
> (XEN) Xen version 4.12.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n
On 23.07.2019 19:58, Roman Shaposhnik wrote:
> No worries. Take a look at the head of the log attached.
One more thing for you to tweak to make the log even more useful:
As per
(XEN) Xen version 4.12.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n Tue Jul 23
17:15:48 UTC 2019
this is a non-debug
On 24/07/2019 12:23, Andrew Cooper wrote:
> On 23/07/2019 18:32, Roman Shaposhnik wrote:
>> Oh, and it seems that that https://downloads.xenproject.org/ SSL
>> certificate expired yesterday -- perhaps somebody can take a look at
>> that.
> Thanks for reporting. It should be being taken care of.
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Oh, and it seems that that https://downloads.xenproject.org/ SSL
> certificate expired yesterday -- perhaps somebody can take a look at
> that.
Thanks for reporting. It should be being taken care of.
~Andrew
On Tue, Jul 23, 2019 at 11:12 AM Andrew Cooper
wrote:
>
> On 23/07/2019 18:58, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
> wrote:
>
> On 23/07/2019 18:48, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> wrote:
>
> On 23/07/2019
On 23/07/2019 18:58, Roman Shaposhnik wrote:
> On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
> wrote:
>> On 23/07/2019 18:48, Roman Shaposhnik wrote:
>>> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
>>> wrote:
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Hi Roger!
>
> I
On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
wrote:
>
> On 23/07/2019 18:48, Roman Shaposhnik wrote:
> > On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> > wrote:
> >> On 23/07/2019 18:32, Roman Shaposhnik wrote:
> >>> Hi Roger!
> >>>
> >>> I applied your patch, removed no-igfx and I still see
On 23/07/2019 18:48, Roman Shaposhnik wrote:
> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> wrote:
>> On 23/07/2019 18:32, Roman Shaposhnik wrote:
>>> Hi Roger!
>>>
>>> I applied your patch, removed no-igfx and I still see the original
>>> problem. Please let me know what other logs/debugs
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Hi Roger!
>
> I applied your patch, removed no-igfx and I still see the original
> problem. Please let me know what other logs/debugs would you need at
> this point.
Please can you collect a full boot log with iommu=debug
~Andrew
Hi Roger!
I applied your patch, removed no-igfx and I still see the original
problem. Please let me know what other logs/debugs would you need at
this point.
Btw, just to make it clear what patch got applied I'm attaching it to
this email.
Oh, and it seems that that
On 23/07/2019 00:36, Roman Shaposhnik wrote:
> Hi Everyone!
>
> Thanks a million for an extremely quick turnaround. I am in my lab
> again next to the box in question.
>
> Should I go ahead and test the latest patch or wait for the official
> one to be submitted?
>
> Thanks,
> Roman.
Use this
.@suse.com; Andrew
> > > Cooper ; boris.ostrov...@oracle.com;
> > > jbeul...@suse.com
> > > Subject: Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
> > > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > > index fef97c82
om; Andrew
> > Cooper ; boris.ostrov...@oracle.com;
> > jbeul...@suse.com
> > Subject: Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index fef97c82f6..88a2430c8c 100644
> > --- a/xe
-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
>
> On Mon, Jul 22, 2019 at 04:03:44PM +0200, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > > > diff --git a/xen/drivers/passthrough/iommu.c
> > > > > b
On Mon, Jul 22, 2019 at 04:03:44PM +0200, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > > diff --git a/xen/drivers/passthrough/iommu.c
> > > > b/xen/drivers/passthrough/iommu.c
> > > > index 79ec6719f5..9d91f0d633 100644
> > > > --- a/xen/drivers/passthrough/iommu.c
> > > >
> -Original Message-
[snip]
> > > diff --git a/xen/drivers/passthrough/iommu.c
> > > b/xen/drivers/passthrough/iommu.c
> > > index 79ec6719f5..9d91f0d633 100644
> > > --- a/xen/drivers/passthrough/iommu.c
> > > +++ b/xen/drivers/passthrough/iommu.c
> > > @@ -185,7 +185,7 @@ void
ndrew Cooper
> > ;
> > boris.ostrov...@oracle.com; jbeul...@suse.com
> > Subject: Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
> >
> > On Mon, Jul 22, 2019 at 08:20:36AM +, Paul Durrant wrote:
> > > > -Original Message-
> >
-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
>
> On Mon, Jul 22, 2019 at 08:20:36AM +, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > > (XEN) Domain heap initialised
> > > > (XEN) ACPI: 32/64X FACS address mismatch in F
On Mon, Jul 22, 2019 at 08:20:36AM +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > (XEN) Domain heap initialised
> > > (XEN) ACPI: 32/64X FACS address mismatch in FADT -
> > > 8ce8ef80/, using 32
> > > (XEN) IOAPIC[0]: apic_id 2, version 32, address
> -Original Message-
[snip]
> > (XEN) Domain heap initialised
> > (XEN) ACPI: 32/64X FACS address mismatch in FADT -
> > 8ce8ef80/, using 32
> > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119
> > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> >
De-htmling...
-
[snip]
For RMRRs themselves, system firmware is well known for abiding by the spec
[citation needed], but an RMRR must be honoured, because the entire purpose of
them is to state "this device won't function without access to this area".
An RMRR in a hole, while a violation
om 4.11.0 we now have to utilize
> iommu=no-igfx
> workaround as per:
> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu
>
> Without the workaround the screen appears to be garbled with colored
> static noise and the following message keeps showing up:
> (XEN)
tech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
>
> After upgrading to Xen 4.12.0 from 4.11.0 we now have to utilize
> iommu=no-igfx
> workaround as per:
> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu
>
> Without the workaround the screen appears to
Hi!
we're using Xen on Advantech ARK-2250 Embedded Box PC:
https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
After upgrading to Xen 4.12.0 from 4.11.0 we now have to utilize iommu=no-igfx
workaround as per:
https
76 matches
Mail list logo
