Displaying 20 results from an estimated 200 matches similar to: "More Coverity-reported issues."
2013 Aug 28
12
[PATCH V2] x86/AMD-Vi: Add additional check for invalid special->handle
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
This patch add an additional logic to check for the often case when the
special->handle is not initialized due to firmware bugs.
but the special->usedid is correct. If users overide this using the
command line option ivrs_ioapic, then it should use the value instead.
---
This patch is supposed to follow the patches:
2013 Sep 12
3
[PATCH 1/1 V3] x86/AMD-Vi: Add additional check for invalid special->handle
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
This patch handle additional cases for IVRS bugs where special->handle
is not correctly initialized for IOAPIC and HPETS due to firmware bugs.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Provide logic in "is_ioapic_overidden()"
Signed-off-by: Jan Beulich <JBeulich@suse.com>
---
2013 Jul 22
69
[xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times.
Hi Jan,
After commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, booting dom0 stalls several times.
Sometimes this results in RCU stall warnings from the dom0 kernel, hitting the "any" key, on normal or serial console, makes the boot continue for a while but it stalls several times.
(It also stalls on shutdown BTW)
I have
2013 Aug 27
2
[PATCH] AMD IOMMU: add missing checks
For one we shouldn''t accept IVHD tables specifying IO-APIC IDs beyond
the limit we support (MAX_IO_APICS, currently 128).
And then we shouldn''t memset() a pointer allocation of which failed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -674,6 +674,13 @@ static u16 __init
2013 Oct 06
17
AMD IOMMU disabled - No Perdev Intremap
Hi!
From other people posting to this list, I know that there has been a
bug related to the issue described in Xen Security Advisory 36 that
disables iommu for some AMD users like me.
However, even when passing "iommu=no-amd-iommu-perdev-intremap" it
still disables i/o virtualisatoin. Related Xen dmesg output:
(XEN) IVHD Error: Invalid IO-APIC 0
(XEN) AMD-Vi: Error initialization
2013 Mar 19
7
[PATCH 0/3] IOMMU errata treatment adjustments
1: IOMMU: properly check whether interrupt remapping is enabled
2: AMD IOMMU: only disable when certain IVRS consistency checks fail
3: VT-d: deal with 5500/5520/X58 errata
Patch 1 and 2 are version 2 of a previously submitted, then
withdrawn patch following up after XSA-36. Patch 3 is version 3 of
a patch previously sent by Malcolm and Andrew.
Signed-off-by: Jan Beulich
2012 Sep 18
4
[PATCH] EHCI/Xen: propagate controller reset information to hypervisor
Just like for the in-tree early console debug port driver, the
hypervisor - when using a debug port based console - also needs to be
told about controller resets, so it can suppress using and then
re-initialize the debug port accordingly.
Other than the in-tree driver, the hypervisor driver actually cares
about doing this only for the device where the debug is port actually
in use, i.e. it needs
2012 Nov 02
5
[PATCH, v3] fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled
Since there''s no possible caller of dbgp_external_startup() and
dbgp_reset_prep() when !USB, there''s no point in building and exporting
these functions in that case. This eliminates a build error under the
conditions listed in the subject, introduced with the merge
f1c6872e4980bc4078cfaead05f892b3d78dea64.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jan
2013 Nov 06
2
HVM crash system on AMD APU A8-6600K
My system reboots when I trying to start any HVM domU. This problem
was described earlier:
http://lists.xen.org/archives/html/xen-devel/2013-08/msg01395.html
My system is openSUSE 13.1 RC2 with Xen 4.3.0
My hardware is
ASRock FM2A75 Pro4
AMD A8-6600K APU
Gigabyte Radeon 7850
8 Gb DDR3 1600Mhz
I have setup serial console and could provide logs your requested.
Attached logs from xl dmesg,
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 201201023:
>
on x86_64:
drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
Full randconfig file is
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 201201023:
>
on x86_64:
drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
Full randconfig file is
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 201201023:
>
on x86_64:
drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
Full randconfig file is
2013 May 03
7
IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
Dear mailinglist,
I own a Gigabyte motherboard GA 970A UD3 with IOMMU support. Since the
update XSA-36 (also part of the latest debian wheezy pkg), the
IO-Virtualisation does not work any more as discussed on this
mailinglist [0] and [1].
I like to ask, if there is an "official" solution in sight.
I''m not sure about my alternatives. How "dangerous" is the
2013 Jul 10
2
[PATCH] x86/HVM: key handler registration functions can be __init
This applies to both SVM and VMX.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -310,7 +310,7 @@ static struct keyhandler vmcb_dump_keyha
.desc = "dump AMD-V VMCBs"
};
-void setup_vmcb_dump(void)
+void __init setup_vmcb_dump(void)
{
register_keyhandler(''v'',
2013 Jun 10
35
Xen 4.3 development update
There are basically three issues we''re waiting to sort out (see below
for more info):
* XSA-55
* cpu hotplug in qemu-upsream
* The MMIO hole issue
Unfortuantely, there is considerable uncertainty about how long it
will take for each of those to complete. We''re hoping to be able to
release maybe on the 19th,
This information will be mirrored on the Xen 4.3 Roadmap wiki page:
2013 Jul 09
6
4.3 regression in booting on a particular platform
Jan,
I was given a machine to diagnose a boot problem on xen 4.3, that used
to work on 4.2, and have bisected to the following changeset:
commit d0d4635d034f202bb401a6efa3ba61530f3854ab
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Nov 22 10:47:58 2012 +0100
implement vmap()
... and use it as basis for a proper ioremap() on x86.
Signed-off-by: Jan Beulich
2013 Nov 25
14
[PATCH] VMX: wbinvd when vmentry under UC
From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 26 Nov 2013 04:53:17 +0800
Subject: [PATCH] VMX: wbinvd when vmentry under UC
This patch flush cache when vmentry back to UC guest, to prevent
cache polluted by hypervisor access guest memory during UC mode.
However, wbinvd is a _very_ time consuming operation, so
1.
2011 Oct 07
4
NVIDIA (including Optimus) laptop owners - please read!
Hi guys and gals,
I'm working on improving nouveau's support for MXM (Mobile PCI Express
Module) chips and need some more data to check my implementation.
To see if you can help, the first thing to do is jump over
to /sys/firmware/acpi/tables and run "grep MXMS *".
[root at nisroch tables]# grep MXMS *
Binary file DSDT matches
[root at nisroch tables]#
If this isn't
2013 Jun 24
2
ehci dbgp reset during boot?
Jan (or others),
I'm seeing an issue with the EHCI debug port functionality, that I'm
wondering whether it is a known limitation of the hardware, or if this
is a bug.
On a particular system that I had limited debug capabilities in the
past (Dell Inspiron 15 i3) I am seeing the debug messages abruptly
stop during boot, followed by garbage that looks like an uninitialized
serial port:
2008 Oct 01
0
[PATCH] [IA64] Compilation fix to cpufreq stuff.
Currently xen-unstable.hg is broken on ia64 and it should be fixed
by Yu''s patch. However he is off this week, so I''m sending
the workaround patch.
[IA64] Compilation fix to cpufreq stuff.
This patch fixes the following compilation error by
defining stubs.
This patch is just band aid patch until those functions are implemented
later.
> .../xen/drivers/built_in.o: In