similar to: [amd iommu] [patch 1/2]Add APCI table support for AMD IOMMU

Signed-off-by: Wei Wang <wei.wang2@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA)

Keir, This patch fixes a Xen start up bug on non-iommu machine. Signed-off-by: Wei Wang <wei.wang2@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter

Signed-off-by: Wei Wang <wei.wang2@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA)

Hi! Changeset 17913 breaks build on *BSD: block-qcow.c:36:20: error: gcrypt.h: No such file or directory cc1: warnings being treated as errors block-qcow.c: In function ''gen_cksum'': block-qcow.c:160: warning: implicit declaration of function ''gcry_md_hash_buffer'' block-qcow.c:160: error: ''GCRY_MD_MD5'' undeclared (first use in this function)

Hi! Attached patch makes git-ioemu compile on NetBSD. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> P.S.: I''m about sending the pieces to qemu-devel. The changes in vl.c already went upstream in qemu''s svn c/s 5646. -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz

Hi! On BSD, mmap()ing files works on on-disk files but not on pseudo filesystems like kernfs or procfs. Therefore, attached patch mmap()s anonymous memory. Linux equivalents are sysfs and procfs to above BSD''s pseudo-filesystems. On Linux, mmap is implemented for sysfs but it is questionable to me how write operations work since (most) files in sysfs have static content. So this patch

Hi Keir, For HVM guests, all cpuid Fn''s going through domain_cpuid() iterate over the loop and then return 0 for all four registers. Guests OS''s and cpuid tools in HVM which query for cpuid Fn 0000.0000 %eax and 8000.0000 %eax, see the value 0 and think, Xen emulates oldish 386/486 CPUs. This leads to strange boot failures, "your CPU does not support long mode" or

Hi! I see these messages from the xen-kernel: (XEN) /usr/src/xen-unstable.hg/xen/include/asm/mm.h:186:d0 Error pfn 100: rd=ffff8300df05c100, od=0000000000000000, caf=00000000, taf=0000000000000000 (XEN) mm.c:636:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 8000000000100125 for dom32753 (XEN) /usr/src/xen-unstable.hg/xen/include/asm/mm.h:186:d0 Error pfn 100:

Hi! Attached patch adds missing entries in xentrace''s formats file to make it recognize all HVM traces. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> Still missing are entries for PV traces. -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer

Hi! Make scrub_heap_pages() print from where to where it scrubs pages. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> This patch uncovers a strange behaviour on 32bit. On 64bit I get this: (XEN) Scrubbing Free RAM 0xffff830000100000 -> 0xffff83003fff0000: ....done. On 32bit I get this: (XEN) Scrubbing Free RAM 0xffc00000 -> 0xdefb0000:

Hi! Don''t allow the compiler to play around with producer/consumer shared across domains. Keir: Please apply this also to Xen 3.2-testing. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer

Hi, Since c/s 18372, building stubdom fails with: cc1: warnings being treated as errors lib/sys.c: In function ''munmap'': lib/sys.c:1182: warning: pointer of type ''void *'' used in arithmetic make[2]: *** [/xen/xen-unstable.hg/stubdom/mini-os-x86_64-grub/lib/sys.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** wait: No child processes.

Add explicit include path for funcs.sh. When the current directory is not in $PATH, then the patch fixes the following errors: Checking check_brctl: .: funcs.sh: not found Checking check_crypto_lib: .: funcs.sh: not found Checking check_curl: .: funcs.sh: not found Checking check_iproute: .: funcs.sh: not found Checking check_python: .: funcs.sh: not found Checking check_python_xml: .: funcs.sh:

Hi! Attached patch makes xenstore functions static which have no prototype and removes unused talloc_open(). Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland

Hi! In struct ioreq are the "addr", "size", "count" and "data" 64bit fields. So handle 64bit operations in stdvga instead of throwing away the upper 32bits (see attached patch). This fixes some noisy xen messages like "invalid io size: 8". Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany

Hi! Attached patch makes functions w/o a prototype static and removes redundant declaration of xs_fire_next_watch(). Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden,

Hi! Attached patch brings in - build fixes for OpenBSD - sprintf() -> snprintf() Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA

Hi, This patch introduces machine check support as described in the pdf. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896

Hi! Attached patch uses calloc() for hash allocation. This makes sure, the allocated memory is always initialized. Also cleanup error handling a bit. On *BSD avoid conflicts with BSD list macros. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG

Hi! Attached patch removes redundant declaration of xc_copy_to_domain_page(). It''s already declared in xenctrl.h. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden,