similar to: [PATCH] x86/mce: Use MCG_CAP MSR to find out number of banks on AMD

Currently number of error reporting register banks is hardcoded to 6 on AMD processors. This may break in virtualized scenarios when a hypervisor prefers to report fewer banks than what the physical HW provides. Since number of supported banks is reported in MSR_IA32_MCG_CAP[7:0] that''s what we should use. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> ---

Boris, Here is the updated patch for determining number of regiter banks on AMD plus a patch removing shared_bank array, as you suggested. Offline/online testing didn''t show any issues. Boris Ostrovsky (2): x86/mce: Replace shared_bank array with is_shared_bank() helper x86/mce: Use MCG_CAP MSR to find out number of banks on AMD arch/x86/kernel/cpu/mcheck/mce_amd.c | 38

U-boot for the arndale board splits the memory in 8 contiguous banks and rewrites the memory node. So most of the memory is lost. As the frametable is only able to handle contiguous memory, use the first contiguous banks and warn if some of the memory banks are not used. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- xen/arch/arm/setup.c | 23 +++++++++++++++++------ 1 file

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

This series of patches makes Xen pass a (somewhat) valid device tree to dom0. The device tree for dom0 is the same as the one supplied to Xen except the memory and chosen nodes are adjusted appropriately. We don''t yet make use of the device tree to map MMIO regions or setup interrupts for the guest and we still include the UART used for Xen''s console. Note that loading Linux

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

Intercept guest reads of MSR_IA32_MCG_CAP and limit the number of memory banks reported to one. This prevents us from trying to read status of non-existent banks when migrated to a machine with fewer banks. Signed-off-by: Ben Guthro Signed-off-by: David Lively <dlively@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi, This is updated xen vMCE design foils, according to comments from community recently. This foils focus on vMCE part of Xen MCA, so as Keir said, it''s some dense. Later Will will present a document to elaborate more, including Intel MCA and surrounding features and Xen implementation. Thanks, Jinsong

This issue I am encountering seems to only happen on multi-socket machines. It also does not help that the only multi-socket box I have is an Romley-EP (so two socket SandyBridge CPUs). The other SandyBridge boxes I''ve (one socket) are not showing this. Granted they are also a different model (42). The problem is that when I run ''perf top'' within an SMP PVHVM guest,

Hi! The MCG_CAP MSR never returns a negative count of available error-reporting banks. Thus make nr_mce_banks unsigned. While here, do some other minor cleanups. 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):

This commit implements the core NBD protocol for the "base:allocation" Block Status replies. --- server/internal.h | 7 + server/protocol.h | 17 +- server/protocol-handshake-newstyle.c | 79 ++++++++- server/protocol.c | 248 +++++++++++++++++++++++++-- 4 files changed, 335 insertions(+), 16 deletions(-) diff --git

--- lib/hivex.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 66 insertions(+), 15 deletions(-) diff --git a/lib/hivex.c b/lib/hivex.c index efc27f8..e3c1e05 100644 --- a/lib/hivex.c +++ b/lib/hivex.c @@ -208,6 +208,19 @@ struct ntreg_sk_record { char sec_desc[1]; /* security info follows */ } __attribute__((__packed__)); +struct

Initially out there as #965245. I strongly prefer to build ARM64 packages on non-ARM systems. Something about my main build machine having twice the cores and twice the clock speed. As such after many builds I've managed to generate a set of patches which appear to mostly function to get functioning cross-builds of Xen. These are NOT a 100% solution. Some packaging hacks were needed. In

* Richard W.M. Jones: > diff --git a/lib/hivex.c b/lib/hivex.c > index e3c1e05..9351ac5 100644 > --- a/lib/hivex.c > +++ b/lib/hivex.c > @@ -1471,7 +1471,7 @@ hivex_value_value (hive_h *h, hive_value_h value, > if (h->msglvl >= 2) > fprintf (stderr, "hivex_value_value: warning: big data block is not " > "valid

On Sun, Jun 23, 2013 at 08:52:05PM +0200, Hilko Bengen wrote: > --- > lib/hivex.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 66 insertions(+), 15 deletions(-) > > diff --git a/lib/hivex.c b/lib/hivex.c > index efc27f8..e3c1e05 100644 > --- a/lib/hivex.c > +++ b/lib/hivex.c > @@ -208,6 +208,19 @@ struct ntreg_sk_record { >

Large values are split into multiple blocks. References to these sub-blocks are kept in a list whose structure seems to be identical to a value list. A "db" record contains information on the number of sub-blocks and a pointer to the list. It is referenced by the vk record. I came across this when comparing the contents of HKLM\SOFTWARE hives from Windows7 systems and finding that

I pushed this one already. It should go into the stable-1.12 branch too. Rich.

We disabled Nagle's algorithm to allow less latency in our responses reaching the client; but as a side effect, it leads to more network overhead when we send a reply split across more than one write(). Take advantage of various means for grouping related writes (Linux' MSG_MORE for sockets, gnutls' corking for TLS) to send a larger packet, and adjust callers to pass in our internal

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

This time around, the numbers are indeed looking better than in v1; and I like the interface better. Eric Blake (2): server: Prefer send() over write() server: Group related transmission send()s server/internal.h | 7 +++- server/connections.c | 51 +++++++++++++++++++++++++--- server/crypto.c | 11 ++++--