* [RFC PATCH v3.1] xSplice design.
@ 2015-07-27 19:20 Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
` (2 more replies)
0 siblings, 3 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-07-27 19:20 UTC (permalink / raw)
To: xen-devel, msw, aliguori, amesserl, rick.harris, paul.voccio,
steven.wilson, major.hayden, josh.kearney, jinsong.liu,
xiantao.zxt, daniel.kiper, elena.ufimtseva, bob.liu, hanweidong,
peter.huangpeng, fanhenglong, liuyingdong, john.liuqiming,
jbeulich, Andrew.Cooper3, jeremy, dslutz, mpohlack
Hey!
Since v3 [http://lists.xen.org/archives/html/xen-devel/2015-07/msg00990.html]
- Nailed down the comments, ingested them in.
- Wrote and tested some code.
RFC v2 [http://lists.xen.org/archives/html/xen-devel/2015-05/msg02142.html]
- Ingested every review comment in.
The patches for the code are a shell - there is no patching done at all and
it is very much just to test out the design and hypercalls. The hard parts
are yet to come :-)
At the Seattle LinuxCon/Xen Summit I will be presenting about xSplice and
referring to this URL. There is also an slot for brainstorming to talk
in details about things we disagree - and there is ample time to talk
during dinner. Martin who has been heavily reviewing the design will be there
and I hope other folks will be there as well to shape the design and
how we want this to work.
The big outstanding issues are how we want to handle preemption. That
is the problem of making an hypercall and waiting for the hypervisor
to do its job (and the VCPU is blocked). In the past some XSAs have come
out to resolve this and I would very much like this to have it addressed at start.
I think the other issues that have been raised should also be discussed
naturally, but the above is crucial (at least for me). I've attached the
patches on how I thought the preemption part could be solved by having an 'worker'
in hypervisor acting on the commands - and we just poll on the status to see
what the hypervisor has done so far.
Lastly, I also plan to add an Wiki to outline the dependency implementation
parts that so far bubbled up - I figured Wiki would be better as some folks
could put their name behind it.
Now please excuse the roughness of the patch and this giant one huge having
everything in it. It ought to be split in three at least: hypervisor, toolstacks
(libxc and libxl) - that is to be done later.
docs/misc/xsplice.h | 80 +++
docs/misc/xsplice.markdown | 1230 +++++++++++++++++++++++++++++++++++++++++
docs/misc/xsplice_test.c | 78 +++
tools/libxc/include/xenctrl.h | 16 +
tools/libxc/xc_misc.c | 183 ++++++
tools/libxc/xc_private.c | 3 +
tools/misc/Makefile | 4 +
tools/misc/xen-xsplice.c | 385 +++++++++++++
xen/common/Makefile | 1 +
xen/common/kernel.c | 11 +
xen/common/keyhandler.c | 8 +-
xen/common/sysctl.c | 5 +
xen/common/version.c | 5 +
xen/common/xsplice.c | 405 ++++++++++++++
xen/include/public/sysctl.h | 66 +++
xen/include/public/version.h | 4 +
xen/include/xen/compile.h.in | 1 +
xen/include/xen/version.h | 1 +
xen/include/xen/xsplice.h | 9 +
19 files changed, 2494 insertions(+), 1 deletion(-)
Konrad Rzeszutek Wilk (2):
xsplice: rfc.v3.1
xsplice: Add hook for build_id
^ permalink raw reply [flat|nested] 170+ messages in thread* [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1
2015-07-27 19:20 [RFC PATCH v3.1] xSplice design Konrad Rzeszutek Wilk
@ 2015-07-27 19:20 ` Konrad Rzeszutek Wilk
2015-07-30 16:47 ` Johannes Erdfelt
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
2 siblings, 1 reply; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-07-27 19:20 UTC (permalink / raw)
To: xen-devel, msw, aliguori, amesserl, rick.harris, paul.voccio,
steven.wilson, major.hayden, josh.kearney, jinsong.liu,
xiantao.zxt, daniel.kiper, elena.ufimtseva, bob.liu, hanweidong,
peter.huangpeng, fanhenglong, liuyingdong, john.liuqiming,
jbeulich, Andrew.Cooper3, jeremy, dslutz, mpohlack
*TODO*:
- XSM add
- Contributs/authors on xsplice.markdown
- Figure out the preemption method (rfc.v4 target). Talk in Seattle?
- Further work - write out an Wiki detailing what implementation
pieces to be done for individual contributions. Do it before
Seattle?
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
docs/misc/xsplice.h | 80 +++
docs/misc/xsplice.markdown | 1230 +++++++++++++++++++++++++++++++++++++++++
docs/misc/xsplice_test.c | 78 +++
tools/libxc/include/xenctrl.h | 16 +
tools/libxc/xc_misc.c | 183 ++++++
tools/misc/Makefile | 4 +
tools/misc/xen-xsplice.c | 360 ++++++++++++
xen/common/Makefile | 1 +
xen/common/keyhandler.c | 8 +-
xen/common/sysctl.c | 5 +
xen/common/xsplice.c | 405 ++++++++++++++
xen/include/public/sysctl.h | 66 +++
xen/include/xen/xsplice.h | 9 +
13 files changed, 2444 insertions(+), 1 deletion(-)
create mode 100644 docs/misc/xsplice.h
create mode 100644 docs/misc/xsplice.markdown
create mode 100644 docs/misc/xsplice_test.c
create mode 100644 tools/misc/xen-xsplice.c
create mode 100644 xen/common/xsplice.c
create mode 100644 xen/include/xen/xsplice.h
diff --git a/docs/misc/xsplice.h b/docs/misc/xsplice.h
new file mode 100644
index 0000000..00061fc
--- /dev/null
+++ b/docs/misc/xsplice.h
@@ -0,0 +1,80 @@
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#define XSPLICE_HOWTO_INLINE 0x1 /* It is an inline replacement. */
+#define XSPLICE_HOWTO_RELOC_PATCH 0x2 /* Add an trampoline. */
+
+#define XSPLICE_HOWTO_FLAG_PC_REL 0x1 /* Is PC relative. */
+#define XSPLICE_HOWOT_FLAG_SIGN 0x2 /* Should the new value be treated as signed value. */
+
+struct xsplice_reloc_howto {
+ uint32_t howto;/* XSPLICE_HOWTO_* */
+ uint32_t flag; /* XSPLICE_HOWTO_FLAG_* */
+ uint32_t size; /* Size, in bytes, of the item to be relocated. */
+ uint32_t r_shift; /* The value the final relocation is shifted right by; used to drop unwanted data from the relocation. */
+ uint64_t mask; /* Bitmask for which parts of the instruction or data are replaced with the relocated value. */
+ uint8_t pad[8]; /* Must be zero. */
+};
+
+struct xsplice_symbol {
+ const char *name; /* The ELF name of the symbol. */
+ const char *label; /* A unique xSplice name for the symbol. */
+ uint8_t pad[16]; /* Must be zero. */
+};
+#define XSPLICE_PATCH_INLINE_TEXT 0x1
+#define XSPLICE_PATCH_INLINE_DATA 0x2
+#define XSPLICE_PATCH_RELOC_TEXT 0x3
+
+struct xsplice_patch {
+ uint32_t type; /* XSPLICE_PATCH_* .*/
+ uint32_t size; /* Size of patch. */
+ uint64_t addr; /* The address of the inline new code (or data). */
+ void *content; /* The bytes to be installed. */
+ uint8_t pad[40]; /* Must be zero. */
+};
+
+#define XSPLICE_SECTION_TEXT 0x00000001 /* Section is in .text */
+#define XSPLICE_SECTION_RODATA 0x00000002 /* Section is in .rodata */
+#define XSPLICE_SECTION_DATA 0x00000004 /* Section is in .data */
+#define XSPLICE_SECTION_STRING 0x00000008 /* Section is in .str */
+
+#define XSPLICE_SECTION_TEXT_INLINE 0x00000200 /* Change is to be inline. */
+#define XSPLICE_SECTION_MATCH_EXACT 0x00000400 /* Must match exactly. */
+#define XSPLICE_SECTION_NO_STACKCHECK 0x00000800 /* Do not check the stack. */
+
+struct xsplice_section {
+ struct xsplice_symbol *symbol; /* The symbol associated with this change. */
+ uint64_t address; /* The address of the section (if known). */
+ uint32_t size; /* The size of the section. */
+ uint32_t flags; /* Various XSPLICE_SECTION_* flags. */
+ uint8_t pad[12]; /* To be zero. */
+};
+
+struct xsplice_reloc {
+ uint64_t addr; /* The address of the relocation (if known). */
+ struct xsplice_symbol *symbol; /* Symbol for this relocation. */
+ int64_t isns_target; /* rest of the ELF addend. This is equal to the offset against the symbol that the relocation refers to. */
+ struct xsplice_reloc_howto *howto; /* Pointer to the above structure. */
+ int64_t isns_added; /* ELF addend resulting from quirks of instruction one of whose operands is the relocation. For example, this is -4 on x86 pc-relative jumps. */
+ uint8_t pad[24]; /* Must be zero. */
+};
+
+struct xsplice_code {
+ struct xsplice_reloc *relocs; /* How to patch it. */
+ uint32_t n_relocs;
+ struct xsplice_section *sections; /* Safety data. */
+ uint32_t n_sections;
+ struct xsplice_patch *patches; /* Patch code and data */
+ uint32_t n_patches;
+ uint8_t pad[28]; /* Must be zero. */
+};
+struct xsplice {
+ uint32_t version;
+ const char *name; /* A sensible name for the patch. Up to 40 characters. */
+ const char *id; /* ID of the hypervisor this binary was built against. */
+ uint32_t id_size;
+ struct xsplice_code *new; /* Pointer to the new code to be patched. */
+ struct xsplice_code *old; /* Pointer to the old code to be checked against. */
+ uint8_t pad[24]; /* Must be zero. */
+};
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
new file mode 100644
index 0000000..02fd4d1
--- /dev/null
+++ b/docs/misc/xsplice.markdown
@@ -0,0 +1,1230 @@
+# xSplice Design v1 (EXTERNAL RFC v3)
+
+## Rationale
+
+A mechanism is required to binarily patch the running hypervisor with new
+opcodes that have come about due to primarily security updates.
+
+This document describes the design of the API that would allow us to
+upload to the hypervisor binary patches.
+
+The document is split in four sections:
+ - Detailed descriptions of the problem statement.
+ - Design of the data structures.
+ - Design of the hypercalls.
+ - Implementation notes that should be taken into consideration.
+
+
+## Glossary
+
+ * splice - patch in the binary code with new opcodes
+ * trampoline - a jump to a new instruction.
+ * payload - telemetries of the old code along with binary blob of the new
+ function (if needed).
+ * reloc - telemetries contained in the payload to construct proper trampoline.
+
+## Multiple ways to patch
+
+The mechanism needs to be flexible to patch the hypervisor in multiple ways
+and be as simple as possible. The compiled code is contiguous in memory with
+no gaps - so we have no luxury of 'moving' existing code and must either
+insert a trampoline to the new code to be executed - or only modify in-place
+the code if there is sufficient space. The placement of new code has to be done
+by hypervisor and the virtual address for the new code is allocated dynamically.
+
+This implies that the hypervisor must compute the new offsets when splicing
+in the new trampoline code. Where the trampoline is added (inside
+the function we are patching or just the callers?) is also important.
+
+To lessen the amount of code in hypervisor, the consumer of the API
+is responsible for identifying which mechanism to employ and how many locations
+to patch. Combinations of modifying in-place code, adding trampoline, etc
+has to be supported. The API should allow read/write any memory within
+the hypervisor virtual address space.
+
+We must also have a mechanism to query what has been applied and a mechanism
+to revert it if needed.
+
+We must also have a mechanism to: (optional) provide an copy of the old code - so
+that the hypervisor can verify it against the code in memory; the new code;
+the symbol name of the function to be patched; or offset from the symbol;
+or virtual address.
+
+The complications that this design will encounter are explained later
+in this document.
+
+## Workflow
+
+
+The expected workflows of higher-level tools that manage multiple patches
+on production machines would be:
+
+ * The first obvious task is loading all available / suggested
+ hotpatches around system start.
+ * Whenever new hotpatches are installed, they should be loaded too.
+ * One wants to query which modules have been loaded at runtime.
+ * If unloading is deemed safe (see unloading below), one may want to
+ support a workflow where a specific hotpatch is marked as bad and
+ unloaded.
+ * If we do no restrict module activation order and want to report tboot
+ state on sequences, we might have a complexity explosion problem, in
+ what system hashes should be considered acceptable.
+
+## Patching code
+
+The first mechanism to patch that comes in mind is in-place replacement.
+That is replace the affected code with new code. Unfortunately the x86
+ISA is variable size which places limits on how much space we have available
+to replace the instructions. That is not a problem if the change is smaller
+than the original opcode and we can fill it with nops. Problems will
+appear if the replacement code is longer.
+
+The second mechanism is by replacing the call or jump to the
+old function with the address of the new function.
+
+A third mechanism is to add a jump to the new function at the
+start of the old function.
+
+### Example of trampoline and in-place splicing
+
+As example we will assume the hypervisor does not have XSA-132 (see
+*domctl/sysctl: don't leak hypervisor stack to toolstacks*
+4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
+the hypervisor with it. The original code looks as so:
+
+<pre>
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
+</pre>
+
+while the new patched hypervisor would be:
+
+<pre>
+ 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
+ 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
+ 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
+</pre>
+
+This is inside the arch_do_domctl. This new change adds 21 extra
+bytes of code which alters all the offsets inside the function. To alter
+these offsets and add the extra 21 bytes of code we might not have enough
+space in .text to squeeze this in.
+
+As such we could simplify this problem by only patching the site
+which calls arch_do_domctl:
+
+<pre>
+<do_domctl>:
+ e8 4b b1 05 00 callq ffff82d08015fbb9 <arch_do_domctl>
+</pre>
+
+with a new address for where the new `arch_do_domctl` would be (this
+area would be allocated dynamically).
+
+Astute readers will wonder what we need to do if we were to patch `do_domctl`
+- which is not called directly by hypervisor but on behalf of the guests via
+the `compat_hypercall_table` and `hypercall_table`.
+Patching the offset in `hypercall_table` for `do_domctl:
+(ffff82d080103079 <do_domctl>:)
+<pre>
+
+ ffff82d08024d490: 79 30
+ ffff82d08024d492: 10 80 d0 82 ff ff
+
+</pre>
+with the new address where the new `do_domctl` is possible. The other
+place where it is used is in `hvm_hypercall64_table` which would need
+to be patched in a similar way. This would require an in-place splicing
+of the new virtual address of `arch_do_domctl`.
+
+In summary this example patched the callee of the affected function by
+ * allocating memory for the new code to live in,
+ * changing the virtual address in all the functions which called the old
+ code (computing the new offset, patching the callq with a new callq).
+ * changing the function pointer tables with the new virtual address of
+ the function (splicing in the new virtual address). Since this table
+ resides in the .rodata section we would need to temporarily change the
+ page table permissions during this part.
+
+
+However it has severe drawbacks - the safety checks which have to make sure
+the function is not on the stack - must also check every caller. For some
+patches this could mean - if there were an sufficient large amount of
+callers - that we would never be able to apply the update.
+
+### Example of different trampoline patching.
+
+An alternative mechanism exists where we can insert a trampoline in the
+existing function to be patched to jump directly to the new code. This
+lessens the locations to be patched to one but it puts pressure on the
+CPU branching logic (I-cache, but it is just one unconditional jump).
+
+For this example we will assume that the hypervisor has not been compiled
+with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
+for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+in `xen_version` hypercall. This function is not called **anywhere** in
+the hypervisor (it is called by the guest) but referenced in the
+`compat_hypercall_table` and `hypercall_table` (and indirectly called
+from that). Patching the offset in `hypercall_table` for the old
+`do_xen_version` (ffff82d080112f9e <do_xen_version>)
+
+</pre>
+ ffff82d08024b270 <hypercall_table>
+ ...
+ ffff82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
+
+</pre>
+with the new address where the new `do_xen_version` is possible. The other
+place where it is used is in `hvm_hypercall64_table` which would need
+to be patched in a similar way. This would require an in-place splicing
+of the new virtual address of `do_xen_version`.
+
+An alternative solution would be to patch insert a trampoline in the
+old `do_xen_version' function to directly jump to the new `do_xen_version`.
+
+<pre>
+ ffff82d080112f9e <do_xen_version>:
+ ffff82d080112f9e: 48 c7 c0 da ff ff ff mov $0xffffffffffffffda,%rax
+ ffff82d080112fa5: 83 ff 09 cmp $0x9,%edi
+ ffff82d080112fa8: 0f 87 24 05 00 00 ja ffff82d0801134d2 <do_xen_version+0x534>
+</pre>
+
+with:
+
+<pre>
+ ffff82d080112f9e <do_xen_version>:
+ ffff82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
+</pre>
+
+which would lessen the amount of patching to just one location.
+
+In summary this example patched the affected function to jump to the
+new replacement function which required:
+ * allocating memory for the new code to live in,
+ * inserting trampoline with new offset in the old function to point to the
+ new function.
+ * Optionally we can insert in the old function a trampoline jump to an function
+ providing an BUG_ON to catch errant code.
+
+The disadvantage of this are that the unconditional jump will consume a small
+I-cache penalty. However the simplicity of the patching and higher chance
+of passing safety checks make this a worthwhile option.
+
+### Security
+
+With this method we can re-write the hypervisor - and as such we **MUST** be
+diligent in only allowing certain guests to perform this operation.
+
+Furthermore with SecureBoot or tboot, we **MUST** also verify the signature
+of the payload to be certain it came from a trusted source and integrity
+was intact.
+
+As such the hypercall **MUST** support an XSM policy to limit what the guest
+is allowed to invoke. If the system is booted with signature checking the
+signature checking will be enforced.
+
+## Design of payload format
+
+The payload **MUST** contain enough data to allow us to apply the update
+and also safely reverse it. As such we **MUST** know:
+
+ * (optional) What the old code is expected to be. We **MUST** be able verify it
+ against the runtime code if old code is included in the payload.
+ * Verify the build-id of hypervisor against the payload build-id.
+ * The locations in memory to be patched. This can be determined dynamically
+ via symbols or via virtual addresses.
+ * The new code (or data) that will be patched in.
+ * Signature to verify the payload.
+
+This binary format can be constructed using an custom binary format but
+there are severe disadvantages of it:
+
+ * The format might need to be changed and we need an mechanism to accommodate
+ that.
+ * It has to be platform agnostic.
+ * Easily constructed using existing tools.
+
+As such having the payload in an ELF file is the sensible way. We would be
+carrying the various sets of structures (and data) in the ELF sections under
+different names and with definitions. The prefix for the ELF section name
+would always be: *.xsplice* to match up to the names of the structures.
+
+Note that every structure has padding. This is added so that the hypervisor
+can re-use those fields as it sees fit.
+
+Earlier design attempted to ineptly explain the relations of the ELF sections
+to each other without using proper ELF mechanism (sh_info, sh_link, data
+structures using Elf_* types, etc). This design will explain in detail
+the structures and how they are used together and not dig in the ELF
+format - except mention that the section names should match the
+structure names.
+
+### ASCII art of structures.
+
+The diagram below is omitting some entries to easy the relationship explanation.
+
+<pre>
+ /---------------------\
+ +->| xsplice_reloc_howto |
+ / \---------------------/
+ /---------------\ 1:1/
+ +->| xsplice_reloc | /
+ / | - howto +--/ 1:1 /----------------\
+ / | - symbol +-------->| xsplice_symbol |
+ 1:N / \---------------/ / \----------------/
+/----------\ /--------------\ / /
+| xsplice | 1:1 | xsplice_code | / 1:1/
+| - new +------->| - relocs +---/ 1:N /-----------------\ /
+| - old +------->| - sections +----------->| xsplice_section | /
+\----------/ | - patches +--\ | - symbol +/ 1:1 /----------------\
+ \--------------/ \ | - addr +------->| .text or .data |
+ \ \----------------/ \----------------/
+ \
+ 1:N \
+ \ /----------------\
+ +-->| xsplice_patch | 1:1 /----------------\
+ | - content +------>| binary code or |
+ \----------------/ | data |
+ \----------------/
+
+</pre>
+
+### xsplice structures
+
+From the top (or left in the above diagram) the structures are:
+
+ * `xsplice`. The top most structure - contains the the name of the update,
+ the id to match against the hypervisor, the pointer to the metadata for
+ the new code and optionally the metadata for the old code.
+
+ * `xsplice_code`. The structure that ties all of this together and defines
+ the payload. Contains arrays of `xsplice_reloc`, `xsplice_section`, and
+ `xsplice_patch`.
+
+ * `xsplice_reloc` contains telemetry used for patching - which describes the
+ targets to be patched and how to do it.
+
+ * `xsplice_section` - the safety data for the code. Contains pointer to the
+ symbol (`xsplice_symbols`) and pointer to the code (`.text`) or data (`.data`),
+ which are to be used during safety and dependency checking.
+
+ * `xsplice_patch`: the description of the new function to be patched in
+ along with the binary code or data.
+
+ * ` xsplice_reloc_howto`: the howto properly construct trampolines for an patch.
+ We may have multiple locations for which we need to insert a trampoline for a
+ payload and each location might require a different way of handling it.
+
+ * `xsplice_symbols `. The symbol that will be patched.
+
+In short the *.xsplice* sections (with `xsplice` being the top) represent
+various structures to define the new code and safety checks for the old
+code (optional). The ELF provides the mechanism to glue it all together when
+loaded in memory.
+
+
+Note that a lot of these ideas are borrowed from kSplice which is
+available at: https://github.com/jirislaby/ksplice
+
+### struct xsplice
+
+The top most structure is quite simple. It defines the name, the id
+of the hypervisor, pointer to the new code & data and an pointer to
+the old code & data (optional).
+
+The `new` code uses all of the `xsplice_*` structures while the
+`old` does not use the `xsplice_reloc` structures.
+
+The sections defining the structures will explicitly state
+when they are not used.
+
+<pre>
+struct xsplice {
+ uint32_t version; /* Version of payload. */
+ const char *name; /* A sensible name for the patch. Up to 40 characters. */
+ const char *id; /* ID of the hypervisor this binary was built against. */
+ uint32_t id_size; /* Size of the ID. */
+ struct xsplice_code *new; /* Pointer to the new code & data to be patched. */
+ struct xsplice_code *old; /* Pointer to the old code & data to be checked against. */
+ uint8_t pad[24]; /* Must be zero. */
+};
+</pre>
+
+The size of this structure should be 64 bytes.
+
+### xsplice_code
+
+The structure embedded within this section ties the other
+structures together. It has the pointers with an start and end
+address for each set of structures. This means that an update
+can be split in multiple changes - for example to accomodate
+an update that contains both code and data and will need patching
+in both .text and .data sections.
+
+<pre>
+struct xsplice_code {
+ struct xsplice_reloc *relocs; /* How to patch it. */
+ uint32_t n_relocs;
+ struct xsplice_section *sections; /* Safety data. */
+ uint32_t n_sections;
+ struct xsplice_patch *patches; /* Patch code and data */
+ uint32_t n_patches;
+ uint8_t pad[28]; /* Must be zero. */
+};
+</pre>
+
+The size of this structure is 64 bytes.
+
+There can be at most two of those structures in the payload.
+One for the `new` and another for the `old` (optional).
+
+If it is for the old code the relocs, and relocs_end values will be ignored.
+
+
+### xsplice_reloc
+
+The `xsplice_code` defines an array of these structures. As such
+an singular structure defines an singular point where to patch the
+hypervisor.
+
+The structure contains the address of the hypervisor (if known),
+the symbol associated with this address, how the patching is to
+be done, and platform specific details.
+
+The `isns_added` is an value to be used to compute the new offset
+due to the quirks of the operands of the instruction. For example
+to patch in an jump operation to the new code - the offset is relative
+to the program counter of the next instruction - hence the offset
+value has to be subtracted by four bytes - hence this would contain -4 .
+
+The `isns_target` is the offset against the symbol.
+
+The relation of this structure with `xsplice_patch` is 1:1, even
+for inline patches. See the section detailing the structure
+`xsplice_reloc_howto`.
+
+The relation of this structure with `xsplice_section` is 1:1.
+
+This structure is as follow:
+
+<pre>
+struct xsplice_reloc {
+ uint64_t addr; /* The address of the relocation (if known). */
+ struct xsplice_symbol *symbol; /* Symbol for this relocation. */
+ int64_t isns_target; /* rest of the ELF addend. This is equal to the offset against the symbol that the relocation refers to. */
+ struct xsplice_reloc_howto *howto; /* Pointer to the above structure. */
+ int64_t isns_added; /* ELF addend resulting from quirks of instruction one of whose operands is the relocation. For example, this is -4 on x86 pc-relative jumps. */
+ uint8_t pad[24]; /* Must be zero. */
+};
+
+</pre>
+
+The size of this structure is 64 bytes.
+
+### xsplice_section
+
+The structure defined in this section is used during pre-patching and
+during patching. Pre-patching it is used to verify that it is safe
+to update with the new changes - and contains safety data on the old code
+and what kind of matching we are to expect.
+
+That is whether the address (either provided or resolved when payload is
+loaded by referencing the symbols) is:
+
+ * in memory,
+ * correct size,
+ * in it's proper ELF section,
+ * has been already patched (or not),
+ * is expected not to be on any CPU stack - (or if it is OK for it be on the CPU stack).
+
+with what we expect it to be.
+
+Some of the checks can be relaxed, as such the `flag` values
+can be or-ed together.
+
+Depending on the time when patching is done, stack checking might not
+be required.
+<pre>
+
+#define XSPLICE_SECTION_TEXT 0x00000001 /* Section is in .text */
+#define XSPLICE_SECTION_RODATA 0x00000002 /* Section is in .rodata */
+#define XSPLICE_SECTION_DATA 0x00000004 /* Section is in .data */
+#define XSPLICE_SECTION_STRING 0x00000008 /* Section is in .str */
+
+#define XSPLICE_SECTION_TEXT_INLINE 0x00000200 /* Change is to be inline. */
+#define XSPLICE_SECTION_MATCH_EXACT 0x00000400 /* Must match exactly. */
+#define XSPLICE_SECTION_NO_STACKCHECK 0x00000800 /* Do not check the stack. */
+
+
+struct xsplice_section {
+ struct xsplice_symbol *symbol; /* The symbol associated with this change. */
+ uint64_t address; /* The address of the section (if known). */
+ uint32_t size; /* The size of the section. */
+ uint32_t flags; /* Various XSPLICE_SECTION_* flags. */
+ uint8_t pad[12]; /* To be zero. */
+};
+
+</pre>
+
+The size of this structure is 32 bytes.
+
+### xsplice_patch
+
+This structure has the binary code (or data) to be patched. Depending on the
+type it can either an inline patch (data or text) or require an relocation
+change (which requires a trampoline). Naturally it also points to a blob
+of the binary data to patch in, and the size of the patch.
+
+The `addr` is used when the patch is for inline change. It can be
+an virtual address or an offset from the symbol start.
+
+If it is an relocation (requiring a trampoline), the `addr` should be zero.
+
+There must be an corresponding ` struct xsplice_reloc` and
+`struct xsplice_section` describing this patch.
+
+<pre>
+#define XSPLICE_PATCH_INLINE_TEXT 0x1
+#define XSPLICE_PATCH_INLINE_DATA 0x2
+#define XSPLICE_PATCH_RELOC_TEXT 0x3
+
+struct xsplice_patch {
+ uint32_t type; /* XSPLICE_PATCH_* .*/
+ uint32_t size; /* Size of patch. */
+ uint64_t addr; /* The address (or offset from symbol) of the inline new code (or data). */
+ void *content; /* The bytes to be installed. */
+ uint8_t pad[40]; /* Must be zero. */
+};
+
+</pre>
+
+The size of this structure is 64 bytes.
+
+### xsplice_symbols
+
+The structure contains an pointer to the name of the ELF symbol
+to be patched and as well an unique name for the symbol.
+
+The `label` is used for diagnostic purposes - such as including the
+name and the offset.
+
+The structure is as follow:
+
+<pre>
+struct xsplice_symbol {
+ const char *name; /* The ELF name of the symbol. */
+ const char *label; /* A unique xSplice name for the symbol. */
+ uint8_t pad[16]; /* Must be zero. */
+};
+</pre>
+
+The size of this structure is 32 bytes.
+
+
+### xsplice_reloc_howto
+
+The howto defines in the detail the change. It contains the type,
+whether the relocation is relative, the size of the relocation,
+bitmask for which parts of the instruction or data are to be replaced,
+amount the final relocation is shifted by (to drop unwanted data), and
+whether the replacement should be interpreted as signed value.
+
+The structure is as follow:
+
+<pre>
+#define XSPLICE_HOWTO_INLINE 0x1 /* It is an inline replacement. */
+#define XSPLICE_HOWTO_RELOC_PATCH 0x2 /* Add a trampoline. */
+
+#define XSPLICE_HOWTO_FLAG_PC_REL 0x1 /* Is PC relative. */
+#define XSPLICE_HOWOT_FLAG_SIGN 0x2 /* Should the new value be treated as signed value. */
+
+struct xsplice_reloc_howto {
+ uint32_t howto; /* XSPLICE_HOWTO_* */
+ uint32_t flag; /* XSPLICE_HOWTO_FLAG_* */
+ uint32_t size; /* Size, in bytes, of the item to be relocated. */
+ uint32_t r_shift; /* The value the final relocation is shifted right by; used to drop unwanted data from the relocation. */
+ uint64_t mask; /* Bitmask for which parts of the instruction or data are replaced with the relocated value. */
+ uint8_t pad[8]; /* Must be zero. */
+};
+
+</pre>
+
+The size of this structure is 32 bytes.
+
+### Example
+
+There is a wealth of information that the payload must have to define a simple
+patch. For this example we will assume that the hypervisor has not been compiled
+with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
+for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+in `xen_version` hypercall. This function is not called **anywhere** in
+the hypervisor (it is called by the guest) but referenced in the
+`compat_hypercall_table` and `hypercall_table` (and indirectly called
+from that). There are two ways to patch this:
+inline patch `hvm_hypercall64_table` and `hvm_hypercall` with a new
+address for the new `do_xen_version` , or insert
+trampoline in `do_xen_version` code. The example will focus on the later.
+
+The `do_xen_version` code is located at virtual address ffff82d080112f9e.
+
+<pre>
+struct xsplice_code xsplice_xsa125;
+struct xsplice_reloc relocs[1];
+struct xsplice_section sections[1];
+struct xsplice_patch patches[1];
+struct xsplice_symbol do_xen_version_symbol;
+struct xsplice_reloc_howto do_xen_version_howto;
+char do_xen_version_new_code[1728];
+
+#ifndef HYPERVISOR_ID
+#define HYPERVISOR_ID "92dd05a61556c554155b1508c9cf67d993336d28"
+#endif
+
+struct xsplice xsa125 = {
+ .name = "xsa125",
+ .id = HYPERVISOR_ID,
+ .old = NULL,
+ .new = &xsplice_xsa125,
+};
+
+struct xsplice_code xsplice_xsa125 = {
+ .relocs = &relocs[0],
+ .n_relocs = 1,
+ .sections = §ions[0],
+ .n_sections = 1,
+ .patches = &patches[0],
+ .n_patches = 1,
+};
+
+struct xsplice_reloc relocs[1] = {
+ {
+ .addr = 0xffff82d080112f9e,
+ .symbol = &do_xen_version_symbol,
+ .isns_target = 0,
+ .howto = &do_xen_version_howto,
+ .isns_added = -4,
+ },
+};
+
+struct xsplice_symbol do_xen_version_symbol = {
+ .name = "do_xen_version",
+ .label = "do_xen_version+<0x0>",
+};
+
+struct xsplice_reloc_howto do_xen_version_howto = {
+ .type = XSPLICE_HOWTO_RELOC_PATCH,
+ .flag = XSPLICE_HOWTO_FLAG_PC_REL,
+ .r_shift = 0,
+ .mask = (-1ULL),
+};
+
+
+struct xsplice_section sections[1] = {
+ {
+ .symbol = &do_xen_version_symbol,
+ .address = 0xffff82d080112f9e,
+ .size = 1728,
+ .flags = XSPLICE_SECTION_TEXT,
+ },
+};
+
+struct xsplice_patch patches[1] = {
+ {
+ .type = XSPLICE_PATCH_RELOC_TEXT,
+ .size = 1728,
+ .addr = 0,
+ .content = &do_xen_version_new_code,
+ },
+};
+
+char do_xen_version_new_code[1728] = { 0x83, 0xff, 0x09, /* And more code. */};
+</pre>
+
+
+## Signature checking requirements.
+
+The signature checking requires that the layout of the data in memory
+**MUST** be same for signature to be verified. This means that the payload
+data layout in ELF format **MUST** match what the hypervisor would be
+expecting such that it can properly do signature verification.
+
+The signature is based on the all of the payloads continuously laid out
+in memory. The signature is to be appended at the end of the ELF payload
+prefixed with the string '~Module signature appended~\n', followed by
+an signature header then followed by the signature, key identifier, and signers
+name.
+
+Specifically the signature header would be:
+
+<pre>
+#define PKEY_ALGO_DSA 0
+#define PKEY_ALGO_RSA 1
+
+#define PKEY_ID_PGP 0 /* OpenPGP generated key ID */
+#define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */
+
+#define HASH_ALGO_MD4 0
+#define HASH_ALGO_MD5 1
+#define HASH_ALGO_SHA1 2
+#define HASH_ALGO_RIPE_MD_160 3
+#define HASH_ALGO_SHA256 4
+#define HASH_ALGO_SHA384 5
+#define HASH_ALGO_SHA512 6
+#define HASH_ALGO_SHA224 7
+#define HASH_ALGO_RIPE_MD_128 8
+#define HASH_ALGO_RIPE_MD_256 9
+#define HASH_ALGO_RIPE_MD_320 10
+#define HASH_ALGO_WP_256 11
+#define HASH_ALGO_WP_384 12
+#define HASH_ALGO_WP_512 13
+#define HASH_ALGO_TGR_128 14
+#define HASH_ALGO_TGR_160 15
+#define HASH_ALGO_TGR_192 16
+
+
+struct elf_payload_signature {
+ u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */
+ u8 hash; /* Digest algorithm: HASH_ALGO_*. */
+ u8 id_type; /* Key identifier type PKEY_ID*. */
+ u8 signer_len; /* Length of signer's name */
+ u8 key_id_len; /* Length of key identifier */
+ u8 __pad[3];
+ __be32 sig_len; /* Length of signature data */
+};
+
+</pre>
+(Note that this has been borrowed from Linux module signature code.).
+
+
+## Hypercalls
+
+We will employ the sub operations of the system management hypercall (sysctl).
+There are to be four sub-operations:
+
+ * upload the payloads.
+ * listing of payloads summary uploaded and their state.
+ * getting an particular payload summary and its state.
+ * command to apply, delete, or revert the payload.
+ * querying of the hypervisor ID (TODO).
+
+Most of the actions are asynchronous therefore the caller is responsible
+to verify that it has been applied properly by retrieving the summary of it
+and verifying that there are no error codes associated with the payload.
+
+We **MUST** make some of them asynchronous due to the nature of patching
+it requires every physical CPU to be lock-step with each other.
+The patching mechanism while an implementation detail, is not an short
+operation and as such the design **MUST** assume it will be an long-running
+operation.
+
+The sub-operations will spell out how preemption is to be handled (if at all).
+
+Furthermore it is possible to have multiple different payloads for the same
+function. As such an unique id per payload has to be visible to allow proper manipulation.
+
+The hypercall is part of the `xen_sysctl`. The top level structure contains
+one uint32_t to determine the sub-operations:
+
+<pre>
+struct xen_sysctl_xsplice_op {
+ uint32_t cmd;
+ union {
+ ... see below ...
+ } u;
+};
+
+</pre>
+while the rest of hypercall specific structures are part of the this structure.
+
+### XEN_SYSCTL_XSPLICE_UPLOAD (0)
+
+Upload a payload to the hypervisor. The payload is verified and if there
+are any issues the proper return code will be returned. The payload is
+not applied at this time - that is controlled by *XEN_SYSCTL_XSPLICE_ACTION*.
+
+The caller provides:
+
+ * `id` unique id.
+ * `payload` the virtual address of where the ELF payload is.
+
+The `id` could be an UUID in mind that stays fixed forever for a given
+hotpatch. It can be embedded into the Elf payload at creation time
+and extracted by tools.
+
+The return value is zero if the payload was succesfully uploaded and the
+signature was verified. Otherwise an EXX return value is provided.
+Duplicate `id` are not supported.
+
+The `payload` is the ELF payload as mentioned in the `Payload format` section.
+
+This operation can be preempted by the hypercall returning EAGAIN.
+This is due to the nature of signature verification - which may require
+SecureBoot firmware calls which are unbounded.
+
+The structure is as follow:
+
+<pre>
+struct xen_sysctl_xsplice_upload {
+ char id[40]; /* IN, name of the patch. */
+ uint64_t size; /* IN, size of the ELF file. */
+ XEN_GUEST_HANDLE_64(uint8) payload; /* ELF file. */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_GET (1)
+
+Retrieve an summary of an specific payload. This caller provides:
+
+ * `id` the unique id.
+ * `status` *MUST* be set to zero.
+
+The `summary` structure contains an summary of payload which includes:
+
+ * `id` the unique id.
+ * `status` - whether it has been:
+ 1. *XSPLICE_STATUS_LOADED* (0x1) has been loaded.
+ 2. *XSPLICE_STATUS_PROGRESS* (0x2) acting on the **XEN_SYSCTL_XSPLICE_ACTION** command.
+ 3. *XSPLICE_STATUS_CHECKED* (0x4) the ELF payload safety checks passed.
+ 4. *XSPLICE_STATUS_APPLIED* (0x8) loaded, checked, and applied.
+ 5. *XSPLICE_STATUS_REVERTED* (0x10) loaded, checked, applied and then also reverted.
+ 6. Negative values is an error. The error would be of EXX format.
+
+The return value is zero on success and EXX on failure. This operation
+is synchronous and does not require preemption.
+
+The structure is as follow:
+
+<pre>
+#define XSPLICE_STATUS_LOADED 0x1
+#define XSPLICE_STATUS_PROGRESS 0x2
+#define XSPLICE_STATUS_CHECKED 0x4
+#define XSPLICE_STATUS_APPLIED 0x8
+#define XSPLICE_STATUS_REVERTED 0x10
+
+struct xen_sysctl_xsplice_summary {
+ char id[40]; /* IN/OUT, name of the patch. */
+ int32_t status; /* OUT */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_LIST (2)
+
+Retrieve an array of abbreviated summary of payloads that are loaded in the
+hypervisor.
+
+The caller provides:
+
+ * `version`. Initially it *MUST* be zero.
+ * `idx` index iterator. On first call *MUST* be zero, subsequent calls varies.
+ * `count` the max number of entries to populate.
+ * `summary` virtual address of where to write payload summaries.
+
+The hypercall returns zero on success and updates the `idx` (index) iterator
+with the number of payloads returned, `count` with the number of remaining
+payloads, and `summary` with an number of payload summaries. The `version`
+is updated on every hypercall - if it varies from one hypercall to another
+the data is stale and further calls could fail.
+
+
+If the hypercall returns E2BIG the `count` is too big and should be
+lowered.
+
+Note that due to the asynchronous nature of hypercalls the domain might have
+added or removed the number of payloads making this information stale. It is
+the responsibility of the toolstack to use the `version` field to check
+between each invocation. if the version differs it should discard the stale
+data and start from scratch.
+
+This operation is synchronous and does not require preemption.
+
+The `summary` structure contains an summary of payload which includes:
+
+ * `version` version of the data.
+ * `id` unique id per payload.
+ * `status` - whether it has been:
+ 1. *XSPLICE_STATUS_LOADED* (0x1) has been loaded.
+ 2. *XSPLICE_STATUS_PROGRESS* (0x2) acting on the **XEN_SYSCTL_XSPLICE_ACTION** command.
+ 3. *XSPLICE_STATUS_CHECKED* (0x4) the ELF payload safety checks passed.
+ 4. *XSPLICE_STATUS_APPLIED* (0x8) loaded, checked, and applied.
+ 5. *XSPLICE_STATUS_REVERTED* (0x10) loaded, checked, applied and then also reverted.
+ 6. Any negative values means there has been error. The value is in EXX format.
+
+The structure is as follow:
+
+<pre>
+struct xen_sysctl_xsplice_list {
+ uint32_t version; /* OUT */
+ uint32_t idx; /* IN/OUT */
+ uint32_t count; /* IN/OUT */
+ XEN_GUEST_HANDLE_64(xen_sysctl_xsplice_summary) summary; /* OUT */
+};
+
+struct xen_sysctl_xsplice_summary {
+ char id[40]; /* OUT, name of the patch. */
+ int32_t status; /* OUT */
+};
+
+</pre>
+### XEN_SYSCTL_XSPLICE_ACTION (3)
+
+Perform an operation on the payload structure referenced by the `id` field.
+The operation request is asynchronous and the status should be retrieved
+by using either **XEN_SYSCTL_XSPLICE_GET** or **XEN_SYSCTL_XSPLICE_LIST** hypercall.
+
+There are two ways about doing preemption. Either via returning back EBUSY
+or the mechanism outlined here.
+
+Doing it in userland would remove any tracking of states in
+the hypervisor - except the simple commands apply, unload, and revert.
+
+However we would not be able to patch all the code that is invoked while
+this hypercall is in progress. That is - the do_domctl, the spinlocks,
+anything put on the stack, etc.
+
+The disadvantage of the mechanism outlined here is that the hypervisor
+code has to keep the state atomic and have an upper bound of time
+on actions. If within the time the operation does not succeed the
+operation would go in error state.
+
+ * `id` the unique id.
+ * `time` the upper bound of time the cmd should take. Zero means infinite.
+ * `cmd` the command requested:
+ 1. *XSPLICE_ACTION_CHECK* (1) check that the payload will apply properly.
+ 2. *XSPLICE_ACTION_UNLOAD* (2) unload the payload.
+ Any further hypercalls against the `id` will result in failure unless
+ **XEN_SYSCTL_XSPLICE_UPLOAD** hypercall is perfomed with same `id`.
+ 3. *XSPLICE_ACTION_REVERT* (3) revert the payload. If the operation takes
+ more time than the upper bound of time the `status` will EBUSY.
+ 4. *XSPLICE_ACTION_APPLY* (4) apply the payload. If the operation takes
+ more time than the upper bound of time the `status` will be EBUSY.
+ 5. *XSPLICE_ACTION_LOADED* is an initial state and cannot be requested.
+
+The return value will be zero unless the provided fields are incorrect.
+
+The structure is as follow:
+
+<pre>
+#define XSPLICE_ACTION_CHECK 1
+#define XSPLICE_ACTION_UNLOAD 2
+#define XSPLICE_ACTION_REVERT 3
+#define XSPLICE_ACTION_APPLY 4
+
+struct xen_sysctl_xsplice_action {
+ char id[40]; /* IN, name of the patch. */
+ uint64_t time; /* IN, upper bound of time (ms) for the operation to take. */
+ uint32_t cmd; /* IN */
+};
+
+</pre>
+
+## State diagrams of XSPLICE_ACTION values.
+
+There is a strict ordering state of what the commands can be.
+The XSPLICE_ACTION prefix has been dropped to easy reading:
+
+<pre>
+ /->\
+ \ /
+ /-------< CHECK
+ | |
+ | +
+ | UNLOAD<--\
+ | \
+ | \
+ /-> APPLY -----------> REVERT --\
+ | |
+ \-------------------------------/
+
+</pre>
+Or an state transition table of valid states:
+<pre>
++-------+-------+--------+--------+---------+-------+------------------+
+| CHECK | APPLY | REVERT | UNLOAD | Current | Next | Result |
++-------+-------+--------+--------+---------+-------+------------------+
+| x | | | | LOADED | CHECK | Check payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | | | x | LOADED | UNLOAD| unload payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| x | | | | CHECK | CHECK | Check payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | x | | | CHECK | APPLY | Apply payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | | | x | CHECK | UNLOAD| Unload payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | | x | | APPLY | REVERT| Revert payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | x | | | REVERT | APPLY | Apply payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+| | | | x | REVERT | UNLOAD| Unload payload. |
++-------+-------+--------+--------+---------+-------+------------------+
+</pre>
+All the other state transitions are invalid.
+
+## Sequence of events.
+
+The normal sequence of events is to:
+
+ 1. *XEN_SYSCTL_XSPLICE_UPLOAD* to upload the payload. If there are errors *STOP* here.
+ 2. *XEN_SYSCTL_XSPLICE_GET* to check the `->status`. If in *XSPLICE_STATUS_PROGRESS* spin. If in *XSPLICE_STATUS_LOADED* go to next step.
+ 3. *XEN_SYSCTL_XSPLICE_ACTION* with *XSPLICE_ACTION_CHECK* command to verify that the payload can be succesfully applied.
+ 4. *XEN_SYSCTL_XSPLICE_GET* to check the `->status`. If in *XSPLICE_STATUS_PROGRESS* spin. If in *XSPLICE_STATUS_CHECKED* go to next step.
+ 5. *XEN_SYSCTL_XSPLICE_ACTION* with *XSPLICE_ACTION_APPLY* to apply the patch.
+ 6. *XEN_SYSCTL_XSPLICE_GET* to check the `->status`. If in *XSPLICE_STATUS_PROGRESS* spin. If in *XSPLICE_STATUS_APPLIED* exit with success.
+
+
+## Addendum
+
+Implementation quirks should not be discussed in a design document.
+
+However these observations can provide aid when developing against this
+document.
+
+
+### Alternative assembler
+
+Alternative assembler is a mechanism to use different instructions depending
+on what the CPU supports. This is done by providing multiple streams of code
+that can be patched in - or if the CPU does not support it - padded with
+`nop` operations. The alternative assembler macros cause the compiler to
+expand the code to place a most generic code in place - emit a special
+ELF .section header to tag this location. During run-time the hypervisor
+can leave the areas alone or patch them with an better suited opcodes.
+
+However these sections are part of .init. and as such can't reasonably be
+subject to patching.
+
+### .rodata sections
+
+The patching might require strings to be updated as well. As such we must be
+also able to patch the strings as needed. This sounds simple - but the compiler
+has a habit of coalescing strings that are the same - which means if we in-place
+alter the strings - other users will be inadvertently affected as well.
+
+This is also where pointers to functions live - and we may need to patch this
+as well. And switch-style jump tables.
+
+To guard against that we must be prepared to do patching similar to
+trampoline patching or in-line depending on the flavour. If we can
+do in-line patching we would need to:
+
+ * alter `.rodata` to be writeable.
+ * inline patch.
+ * alter `.rodata` to be read-only.
+
+If are doing trampoline patching we would need to:
+
+ * allocate a new memory location for the string.
+ * all locations which use this string will have to be updated to use the
+ offset to the string.
+ * mark the region RO when we are done.
+
+### .bss and .data sections.
+
+Patching writable data is not suitable as it is unclear what should be done
+depending on the current state of data. As such it should not be attempted.
+
+
+### Patching code which is in the stack.
+
+We should not patch the code which is on the stack. That can lead
+to corruption.
+
+### Inline patching
+
+The hypervisor should verify that the in-place patching would fit within
+the code or data.
+
+### Trampoline (e9 opcode)
+
+The e9 opcode used for jmpq uses a 32-bit signed displacement. That means
+we are limited to up to 2GB of virtual address to place the new code
+from the old code. That should not be a problem since Xen hypervisor has
+a very small footprint.
+
+However if we need - we can always add two trampolines. One at the 2GB
+limit that calls the next trampoline.
+
+Please note there is a small limitation for trampolines in
+function entries: The target function (+ trailing padding) must be able
+to accomodate the trampoline. On x86 with +-2 GB relative jumps,
+this means 5 bytes are required.
+
+Depending on compiler settings, there are several functions in Xen that
+are smaller (without inter-function padding).
+
+<pre>
+readelf -sW xen-syms | grep " FUNC " | \
+ awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
+
+...
+3 FUNC LOCAL wbinvd_ipi
+3 FUNC LOCAL shadow_l1_index
+...
+</pre>
+A compile-time check for, e.g., a minimum alignment of functions or a
+runtime check that verifies symbol size (+ padding to next symbols) for
+that in the hypervisor is advised.
+
+### When to patch
+
+During the discussion on the design two candidates bubbled where
+the call stack for each CPU would be deterministic. This would
+minimize the chance of the patch not being applied due to safety
+checks failing.
+
+#### Rendezvous code instead of stop_machine for patching
+
+The hypervisor's time rendezvous code runs synchronously across all CPUs
+every second. Using the stop_machine to patch can stall the time rendezvous
+code and result in NMI. As such having the patching be done at the tail
+of rendezvous code should avoid this problem.
+
+However the entrance point for that code is
+do_softirq->timer_softirq_action->time_calibration
+which ends up calling on_selected_cpus on remote CPUs.
+
+The remote CPUs receive CALL_FUNCTION_VECTOR IPI and execute the
+desired function.
+
+
+#### Before entering the guest code.
+
+Before we call VMXResume we check whether any soft IRQs need to be executed.
+This is a good spot because all Xen stacks are effectively empty at
+that point.
+
+To randezvous all the CPUs an barrier with an maximum timeout (which
+could be adjusted), combined with forcing all other CPUs through the
+hypervisor with IPIs, can be utilized to have all the CPUs be lockstep.
+
+The approach is similar in concept to stop_machine and the time rendezvous
+but is time-bound. However the local CPU stack is much shorter and
+a lot more deterministic.
+
+### Compiling the hypervisor code
+
+Hotpatch generation often requires support for compiling the target
+with -ffunction-sections / -fdata-sections. Changes would have to
+be done to the linker scripts to support this.
+
+
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+The author of this design envisions objdump and objcopy along
+with special GCC parameters (see above) to create .o.xsplice files
+which can be used to splice an ELF with the new payload.
+
+The ksplice code can provide inspiration.
+
+### Exception tables and symbol tables growth
+
+We may need support for adapting or augmenting exception tables if
+patching such code. Hotpatches may need to bring their own small
+exception tables (similar to how Linux modules support this).
+
+If supporting hotpatches that introduce additional exception-locations
+is not important, one could also change the exception table in-place
+and reorder it afterwards.
+
+
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch that subsumes and replaces all previous ones.
+ Over the life-time of patching the hypervisor this large patch
+ grows to accumulate all the code changes.
+ * Hotpatch stack - where an mechanism exists that loads the hotpatches
+ in the same order they were built in. We would need an build-id
+ of the hypevisor to make sure the hot-patches are build against the
+ correct build.
+ * Payload containing the old code to check against that. That allows
+ the hotpatches to be loaded indepedently (if they don't overlap) - or
+ if the old code also containst previously patched code - even if they
+ overlap.
+
+The disadvantage of the first large patch is that it can grow over
+time and not provide an bisection mechanism to identify faulty patches.
+
+The hot-patch stack puts stricts requirements on the order of the patches
+being loaded and requires an hypervisor build-id to match against.
+
+The old code allows much more flexibility and an additional guard,
+but is more complex to implement.
+
+### Hypervisor ID (buid-id)
+
+The build-id can help with:
+
+ * Prevent loading of wrong hotpatches (intended for other builds)
+
+ * Allow to identify suitable hotpatches on disk and help with runtime
+ tooling (if laid out using build ID)
+
+The build-id (aka hypervisor id) can be easily obtained by utilizing
+the ld --build-id operatin which (copied from ld):
+
+<pre>
+--build-id
+ --build-id=style
+ Request creation of ".note.gnu.build-id" ELF note section. The contents of the note are unique bits identifying this
+ linked file. style can be "uuid" to use 128 random bits, "sha1" to use a 160-bit SHA1 hash on the normative parts of the
+ output contents, "md5" to use a 128-bit MD5 hash on the normative parts of the output contents, or "0xhexstring" to use a
+ chosen bit string specified as an even number of hexadecimal digits ("-" and ":" characters between digit pairs are
+ ignored). If style is omitted, "sha1" is used.
+
+ The "md5" and "sha1" styles produces an identifier that is always the same in an identical output file, but will be
+ unique among all nonidentical output files. It is not intended to be compared as a checksum for the file's contents. A
+ linked file may be changed later by other tools, but the build ID bit string identifying the original linked file does
+ not change.
+
+ Passing "none" for style disables the setting from any "--build-id" options earlier on the command line.
+
+</pre>
+
+### Symbol names
+
+
+Xen as it is now, has a couple of non-unique symbol names which will
+make runtime symbol identification hard. Sometimes, static symbols
+simply have the same name in C files, sometimes such symbols get
+included via header files, and some C files are also compiled
+multiple times and linked under different names (guest_walk.c).
+
+As such we need to modify the linker to make sure that the symbol
+table qualifies also symbols by their source file name.
+
+For the awkward situations in which C-files are compiled multiple
+times patches we would need to some modification in the Xen code.
+
+
+The convention for file-type symbols (that would allow to map many
+symbols to their compilation unit) says that only the basename (i.e.,
+without directories) is embedded. This creates another layer of
+confusion for duplicate file names in the build tree.
+
+That would have to be resolved.
+
+<pre>
+> find . -name \*.c -print0 | xargs -0 -n1 basename | sort | uniq -c | sort -n | tail -n10
+ 3 shutdown.c
+ 3 sysctl.c
+ 3 time.c
+ 3 xenoprof.c
+ 4 gdbstub.c
+ 4 irq.c
+ 5 domain.c
+ 5 mm.c
+ 5 pci.c
+ 5 traps.c
+</pre>
+
+### Security
+
+Only the privileged domain should be allowed to do this operation.
+
diff --git a/docs/misc/xsplice_test.c b/docs/misc/xsplice_test.c
new file mode 100644
index 0000000..6e0cf93
--- /dev/null
+++ b/docs/misc/xsplice_test.c
@@ -0,0 +1,78 @@
+#include "xsplice.h"
+#include <stdio.h>
+
+struct xsplice_code xsplice_xsa125;
+struct xsplice_reloc relocs[1];
+struct xsplice_section sections[1];
+struct xsplice_patch patches[1];
+struct xsplice_symbol do_xen_version_symbol;
+struct xsplice_reloc_howto do_xen_version_howto;
+char do_xen_version_new_code[1728];
+
+#ifndef HYPERVISOR_ID
+#define HYPERVISOR_ID "Xen 4.6-unstable-g9348394"
+#endif
+
+struct xsplice xsa125 = {
+ .name = "xsa125",
+ .id = HYPERVISOR_ID,
+ .old = NULL,
+ .new = &xsplice_xsa125,
+};
+
+struct xsplice_code xsplice_xsa125 = {
+ .relocs = &relocs[0],
+ .n_relocs = 1,
+ .sections = §ions[0],
+ .n_sections = 1,
+ .patches = &patches[0],
+ .n_patches = 1,
+};
+
+struct xsplice_reloc relocs[1] = {
+ {
+ .addr = 0xffff82d080112f9e,
+ .symbol = &do_xen_version_symbol,
+ .isns_target = 0,
+ .howto = &do_xen_version_howto,
+ .isns_added = -4,
+ },
+};
+
+struct xsplice_symbol do_xen_version_symbol = {
+ .name = "do_xen_version",
+ .label = "do_xen_version+<0x0>",
+};
+
+struct xsplice_reloc_howto do_xen_version_howto = {
+ .howto = XSPLICE_HOWTO_RELOC_PATCH,
+ .flag = XSPLICE_HOWTO_FLAG_PC_REL,
+ .r_shift = 0,
+ .mask = (-1ULL),
+};
+
+
+struct xsplice_section sections[1] = {
+ {
+ .symbol = &do_xen_version_symbol,
+ .address = 0xffff82d080112f9e,
+ .size = 1728,
+ .flags = XSPLICE_SECTION_TEXT,
+ },
+};
+
+struct xsplice_patch patches[1] = {
+ {
+ .type = XSPLICE_PATCH_RELOC_TEXT,
+ .size = 1728,
+ .addr = 0,
+ .content = &do_xen_version_new_code,
+ },
+};
+
+char do_xen_version_new_code[1728] = { 0x83, 0xff, 0x09, };
+
+void main()
+{
+ printf("%s\n", xsa125.name);
+}
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index ac7e5fd..9ef39fd 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2828,6 +2828,22 @@ int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
uint32_t *cos_max, uint32_t *cbm_len);
#endif
+int xc_xsplice_upload(xc_interface *xch,
+ char *id, char *payload, uint32_t size);
+
+int xc_xsplice_get(xc_interface *xch,
+ char *id,
+ xen_sysctl_xsplice_summary_t *summary);
+
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+ xen_sysctl_xsplice_summary_t *info, unsigned int *done,
+ unsigned int *left);
+
+int xc_xsplice_apply(xc_interface *xch, char *id);
+int xc_xsplice_revert(xc_interface *xch, char *id);
+int xc_xsplice_unload(xc_interface *xch, char *id);
+int xc_xsplice_check(xc_interface *xch, char *id);
+
#endif /* XENCTRL_H */
/*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index b827bbb..bb91930 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -719,6 +719,189 @@ int xc_hvm_inject_trap(
return rc;
}
+int xc_xsplice_upload(xc_interface *xch,
+ char *id,
+ char *payload,
+ uint32_t size)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ DECLARE_HYPERCALL_BOUNCE(payload, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+ if ( !id || !payload )
+ return -1;
+
+ if ( xc_hypercall_bounce_pre(xch, payload) )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_UPLOAD;
+ sysctl.u.xsplice.u.upload.size = size;
+ memcpy(sysctl.u.xsplice.u.upload.id, id, XEN_XSPLICE_ID_SIZE);
+ set_xen_guest_handle(sysctl.u.xsplice.u.upload.payload, payload);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ xc_hypercall_bounce_post(xch, payload);
+
+ return rc;
+}
+
+int xc_xsplice_get(xc_interface *xch,
+ char *id,
+ xen_sysctl_xsplice_summary_t *summary)
+{
+ int rc;
+ DECLARE_SYSCTL;
+
+ if ( !id )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_GET;
+ sysctl.u.xsplice.u.get.status = 0;
+ memcpy(sysctl.u.xsplice.u.get.id, id, XEN_XSPLICE_ID_SIZE);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ memcpy(summary, &sysctl.u.xsplice.u.get, sizeof(*summary));
+
+ return rc;
+}
+
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+ xen_sysctl_xsplice_summary_t *info, unsigned int *done,
+ unsigned int *left)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ DECLARE_HYPERCALL_BOUNCE(info, 0 /* adjust later. */, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+ uint32_t max_batch_sz, nr;
+ uint32_t version = 0, retries = 0;
+ uint32_t adjust = 0;
+
+ if ( !max )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_LIST;
+ sysctl.u.xsplice.u.list.version = 0;
+ sysctl.u.xsplice.u.list.idx = start;
+
+ max_batch_sz = max;
+
+ *done = 0;
+ *left = 0;
+ do {
+ if ( adjust )
+ adjust = 0; /* Used when adjusting the 'max_batch_sz' or 'retries'. */
+
+ nr = min(max - *done, max_batch_sz);
+
+ sysctl.u.xsplice.u.list.nr = nr;
+ HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info));
+
+ /* Move the pointer to proper offset into 'info'. */
+ (HYPERCALL_BUFFER(info))->ubuf = info + *done;
+ if ( xc_hypercall_bounce_pre(xch, info) )
+ return -1;
+
+ set_xen_guest_handle(sysctl.u.xsplice.u.list.summary, info);
+
+ rc = do_sysctl(xch, &sysctl);
+ if ( rc < 0 && errno == E2BIG )
+ {
+ if ( max_batch_sz <= 1 )
+ break;
+ max_batch_sz >>= 1;
+ adjust = 1; /* For the loop conditional to let us loop again. */
+ xc_hypercall_bounce_post(xch, info); /* No memory leaks! */
+ continue;
+ }
+ if ( rc < 0 ) /* For all other errors we bail out. */
+ break;
+
+ if ( !version )
+ version = sysctl.u.xsplice.u.list.version;
+
+ if ( sysctl.u.xsplice.u.list.version != version )
+ {
+ /* TODO: retries should be configurable? */
+ if ( retries++ > 3 )
+ {
+ rc = -1;
+ errno = EBUSY;
+ break;
+ }
+ *done = 0; /* Retry from scratch. */
+ version = sysctl.u.xsplice.u.list.version;
+ adjust = 1; /* And make sure we continue in the loop. */
+ xc_hypercall_bounce_post(xch, info); /* No memory leaks! */
+ continue;
+ }
+
+ /* We should never hit this, but just in case. */
+ if ( rc > nr )
+ {
+ errno = EINVAL; /* Overflow! */
+ rc = -1;
+ break;
+ }
+ *left = sysctl.u.xsplice.u.list.nr; /* Total remaining count. */
+ /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */
+ HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info)));
+ /* Bounce the data and free the bounce buffer. */
+ xc_hypercall_bounce_post(xch, info);
+ /* And update how many elements of info we have copied into. */
+ *done += rc;
+ /* Update idx. */
+ sysctl.u.xsplice.u.list.idx = rc;
+ } while ( adjust || (*done < max && *left != 0) );
+
+ return rc > 0 ? 0 : rc;
+}
+
+static int _xc_xsplice_action(xc_interface *xch,
+ char *id,
+ unsigned int action)
+{
+ int rc;
+ DECLARE_SYSCTL;
+
+ if ( !id )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_ACTION;
+ sysctl.u.xsplice.u.action.cmd = action;
+ sysctl.u.xsplice.u.action.time = 0; /* TODO */
+ memcpy(sysctl.u.xsplice.u.action.id, id, XEN_XSPLICE_ID_SIZE);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ return rc;
+}
+
+int xc_xsplice_apply(xc_interface *xch, char *id)
+{
+ return _xc_xsplice_action(xch, id, XSPLICE_ACTION_APPLY);
+}
+
+int xc_xsplice_revert(xc_interface *xch, char *id)
+{
+ return _xc_xsplice_action(xch, id, XSPLICE_ACTION_REVERT);
+}
+
+int xc_xsplice_unload(xc_interface *xch, char *id)
+{
+ return _xc_xsplice_action(xch, id, XSPLICE_ACTION_UNLOAD);
+}
+
+int xc_xsplice_check(xc_interface *xch, char *id)
+{
+ return _xc_xsplice_action(xch, id, XSPLICE_ACTION_CHECK);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index c4490f3..c46873e 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,7 @@ INSTALL_SBIN += xenlockprof
INSTALL_SBIN += xenperf
INSTALL_SBIN += xenpm
INSTALL_SBIN += xenwatchdogd
+INSTALL_SBIN += xen-xsplice
INSTALL_SBIN += $(INSTALL_SBIN-y)
# Everything to be installed in a private bin/
@@ -98,6 +99,9 @@ xen-mfndump: xen-mfndump.o
xenwatchdogd: xenwatchdogd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+xen-xsplice: xen-xsplice.o
+ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
new file mode 100644
index 0000000..7cf9879
--- /dev/null
+++ b/tools/misc/xen-xsplice.c
@@ -0,0 +1,360 @@
+#include <xenctrl.h>
+#include <xenstore.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <fcntl.h>
+static xc_interface *xch;
+
+void show_help(void)
+{
+ fprintf(stderr,
+ "xen-xsplice: Xsplice test tool\n"
+ "Usage: xen-xsplice <command> [args]\n"
+ " <id> An unique name of payload. Up to 40 characters.\n"
+ "Commands:\n"
+ " help display this help\n"
+ " upload <id> <file> upload file <cpuid> with <id> name\n"
+ " list list payloads uploaded.\n"
+ " apply <id> apply <id> patch.\n"
+ " revert <id> revert id <id> patch.\n"
+ " unload <id> unload id <id> patch.\n"
+ " check <id> check id <id> patch.\n"
+ );
+}
+
+/* wrapper function */
+static int help_func(int argc, char *argv[])
+{
+ show_help();
+ return 0;
+}
+
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+static const char *status2str(long status)
+{
+#define STATUS(x) [XSPLICE_STATUS_##x] = #x
+ static const char *const names[] = {
+ STATUS(LOADED),
+ STATUS(PROGRESS),
+ STATUS(CHECKED),
+ STATUS(APPLIED),
+ STATUS(REVERTED),
+ };
+
+ if (status >= ARRAY_SIZE(names))
+ return "unknown";
+
+ if (status < 0)
+ return "-EXX";
+
+ if (!names[status])
+ return "unknown";
+
+ return names[status];
+}
+
+#define MAX 11
+static int list_func(int argc, char *argv[])
+{
+ unsigned int idx, done, left, rc, i;
+ xen_sysctl_xsplice_summary_t *info;
+
+ if ( argc )
+ {
+ show_help();
+ return -1;
+ }
+ idx = left = 0;
+ info = malloc(sizeof(*info) * MAX);
+ if ( !info )
+ {
+ fprintf(stderr, "Could not allocate buffer!\n");
+ return ENOMEM;
+ }
+ fprintf(stdout," ID | status\n"
+ "----------------------------------------+------------\n");
+ do {
+ done = 0;
+ memset(info, 'A', sizeof(*info) * MAX); /* Optional. */
+ rc = xc_xsplice_list(xch, MAX, idx, info, &done, &left);
+ if ( rc )
+ {
+ fprintf(stderr, "Failed to list %d/%d: %d(%s)!\n", idx, left, errno, strerror(errno));
+ return errno;
+ }
+ for ( i = 0; i < done; i++ )
+ {
+ fprintf(stdout, "%-40s| ", info[i].id);
+ if ( info[i].status < 0 )
+ fprintf(stdout, "%s\n", strerror(info[i].status));
+ else
+ fprintf(stdout, "%s\n", status2str(info[i].status));
+ }
+ idx += done;
+ } while ( left );
+
+ return 0;
+}
+
+static int get_id(int argc, char *argv[], char *id)
+{
+ ssize_t len = strlen(argv[0]);
+ if ( len > XEN_XSPLICE_ID_SIZE )
+ {
+ fprintf(stderr, "ID MUST be %d characters!\n", XEN_XSPLICE_ID_SIZE);
+ errno = EINVAL;
+ return errno;
+ }
+ /* Don't want any funny strings from the stack. */
+ memset(id, 0, XEN_XSPLICE_ID_SIZE);
+ strncpy(id, argv[0], len);
+ return 0;
+}
+
+static int upload_func(int argc, char *argv[])
+{
+ char *filename;
+ char id[XEN_XSPLICE_ID_SIZE];
+ int fd = 0, rc;
+ struct stat buf;
+ unsigned char *fbuf;
+ ssize_t len;
+ DECLARE_HYPERCALL_BUFFER(char, payload);
+
+ if ( argc != 2 )
+ {
+ show_help();
+ return -1;
+ }
+
+ if ( get_id(argc, argv, id) )
+ return EINVAL;
+
+ filename = argv[1];
+ fd = open(filename, O_RDONLY);
+ if ( fd < 0 )
+ {
+ fprintf(stderr, "Could not open %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ return errno;
+ }
+ if ( stat(filename, &buf) != 0 )
+ {
+ fprintf(stderr, "Could not get right size %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ close(fd);
+ return errno;
+ }
+
+ len = buf.st_size;
+ fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
+ if ( fbuf == MAP_FAILED )
+ {
+ fprintf(stderr,"Could not map: %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ close (fd);
+ return errno;
+ }
+ printf("Uploading %s (%ld bytes)\n", filename, len);
+ payload = xc_hypercall_buffer_alloc(xch, payload, len);
+ memcpy(payload, fbuf, len);
+
+ rc = xc_xsplice_upload(xch, id, payload, len);
+ if ( rc )
+ {
+ fprintf(stderr, "Upload failed: %s, error: %d(%s)!\n",
+ filename, errno, strerror(errno));
+ goto out;
+ }
+ xc_hypercall_buffer_free(xch, payload);
+
+out:
+ if ( munmap( fbuf, len) )
+ {
+ fprintf(stderr, "Could not unmap!? error: %d(%s)!\n",
+ errno, strerror(errno));
+ rc = errno;
+ }
+ close(fd);
+
+ return rc;
+}
+
+struct {
+ int allow; /* State it must be in to call function. */
+ int expected; /* The state to be in after the function. */
+ const char *name;
+ int (*function)(xc_interface *xch, char *id);
+ unsigned int executed; /* Has the function been called?. */
+} action_options[] = {
+ { .allow = XSPLICE_STATUS_CHECKED | XSPLICE_STATUS_REVERTED,
+ .expected = XSPLICE_STATUS_APPLIED,
+ .name = "apply",
+ .function = xc_xsplice_apply,
+ },
+ { .allow = XSPLICE_STATUS_APPLIED,
+ .expected = XSPLICE_STATUS_REVERTED,
+ .name = "revert",
+ .function = xc_xsplice_revert,
+ },
+ { .allow = XSPLICE_STATUS_CHECKED | XSPLICE_STATUS_REVERTED | XSPLICE_STATUS_LOADED,
+ .expected = ENOENT,
+ .name = "unload",
+ .function = xc_xsplice_unload,
+ },
+ { .allow = XSPLICE_STATUS_CHECKED | XSPLICE_STATUS_LOADED,
+ .expected = XSPLICE_STATUS_CHECKED,
+ .name = "check",
+ .function = xc_xsplice_check
+ },
+};
+
+int action_func(int argc, char *argv[], unsigned int idx)
+{
+ char id[40];
+ int rc;
+ xen_sysctl_xsplice_summary_t summary;
+ unsigned int retry = 0;
+
+ if ( argc != 1 )
+ {
+ show_help();
+ return -1;
+ }
+
+ if ( get_id(argc, argv, id) )
+ return EINVAL;
+
+ do {
+ rc = xc_xsplice_get(xch, id, &summary);
+ /* N.B. Successfull unload will return ENOENT. */
+ if ( rc )
+ {
+ rc = errno; /* rc is just -1 and we want proper EXX. */
+ break;
+ }
+
+ if ( summary.status < 0 )
+ { /* We report it outside the loop. */
+ rc = summary.status;
+ break;
+ }
+ if ( summary.status == XSPLICE_STATUS_PROGRESS )
+ {
+ if ( !action_options[idx].executed )
+ {
+ printf("%s is in progress and we didn't initiate it!\n", id);
+ errno = EBUSY;
+ rc = -1;
+ break;
+ }
+ if ( retry++ < 30 )
+ {
+ printf(".");
+ sleep(1);
+ continue;
+ }
+ printf("%s: Waited more than 30 seconds! Bailing out.\n", id);
+ errno = EBUSY;
+ rc = -1;
+ break;
+ }
+ /* We use rc outside loop to deal with EXX type expected values. */
+ rc = summary.status;
+ if ( action_options[idx].expected == rc ) /* Yeey! */
+ break;
+
+ if ( action_options[idx].allow & rc )
+ {
+ if ( action_options[idx].executed )
+ {
+ printf(" (0x%x vs 0x%x) state not reached!?\n",
+ action_options[idx].expected, rc);
+ errno = EINVAL;
+ break;
+ }
+ printf("%s: State is 0x%x, ok are 0x%x. Commencing %s:",
+ id, rc, action_options[idx].allow,
+ action_options[idx].name);
+
+ rc = action_options[idx].function(xch, id);
+ if ( rc ) /* We report it outside the loop. */
+ break;
+
+ action_options[idx].executed = 1;
+ rc = 1; /* Loop again so we can display the dots. */
+ } else {
+ printf("%s: in wrong state (0x%x), expected 0x%x\n",
+ id, rc, action_options[idx].expected);
+ errno = EINVAL;
+ rc = -1;
+ break;
+ }
+ } while ( rc > 0 );
+
+ if ( action_options[idx].expected == rc )
+ {
+ printf("completed!\n");
+ rc = 0;
+ } else
+ printf("%s failed with %d(%s)\n", id, errno, strerror(errno));
+
+ return rc;
+}
+struct {
+ const char *name;
+ int (*function)(int argc, char *argv[]);
+} main_options[] = {
+ { "help", help_func },
+ { "list", list_func },
+ { "upload", upload_func },
+};
+
+int main(int argc, char *argv[])
+{
+ int i, j, ret;
+
+ if ( argc <= 1 )
+ {
+ show_help();
+ return 0;
+ }
+ for ( i = 0; i < ARRAY_SIZE(main_options); i++ )
+ if (!strncmp(main_options[i].name, argv[1], strlen(argv[1])))
+ break;
+
+ if ( i == ARRAY_SIZE(main_options) )
+ {
+ for ( j = 0; j < ARRAY_SIZE(action_options); j++ )
+ if (!strncmp(action_options[j].name, argv[1], strlen(argv[1])))
+ break;
+
+ if ( j == ARRAY_SIZE(action_options) )
+ {
+ fprintf(stderr, "Unrecognised command '%s' -- try "
+ "'xen-xsplice help'\n", argv[1]);
+ return 1;
+ }
+ }
+
+ xch = xc_interface_open(0,0,0);
+ if ( !xch )
+ {
+ fprintf(stderr, "failed to get the handler\n");
+ return 0;
+ }
+
+ if ( i == ARRAY_SIZE(main_options) )
+ ret = action_func(argc -2, argv + 2, j);
+ else
+ ret = main_options[i].function(argc -2, argv + 2);
+
+ xc_interface_close(xch);
+
+ return !!ret;
+}
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3fdf931..7769e5c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -55,6 +55,7 @@ obj-y += vmap.o
obj-y += vsprintf.o
obj-y += wait.o
obj-y += xmalloc_tlsf.o
+obj-y += xsplice.o
obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 5d21e48..1d4574a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -18,6 +18,7 @@
#include <xen/mm.h>
#include <xen/watchdog.h>
#include <xen/init.h>
+#include <xen/xsplice.h>
#include <asm/debugger.h>
#include <asm/div64.h>
@@ -455,6 +456,11 @@ static struct keyhandler spinlock_reset_keyhandler = {
.desc = "reset lock profile info"
};
#endif
+static struct keyhandler xsplice_printall_keyhandler = {
+ .diagnostic = 1,
+ .u.fn = xsplice_printall,
+ .desc = "print splicing information"
+};
static void run_all_nonirq_keyhandlers(unsigned long unused)
{
@@ -567,7 +573,7 @@ void __init initialize_keytable(void)
register_keyhandler('l', &spinlock_printall_keyhandler);
register_keyhandler('L', &spinlock_reset_keyhandler);
#endif
-
+ register_keyhandler('x', &xsplice_printall_keyhandler);
}
/*
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f1c0c76..641bb25 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,6 +27,7 @@
#include <xsm/xsm.h>
#include <xen/pmstat.h>
#include <xen/gcov.h>
+#include <xen/xsplice.h>
long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
{
@@ -399,6 +400,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
ret = sysctl_coverage_op(&op->u.coverage_op);
break;
#endif
+ case XEN_SYSCTL_xsplice_op:
+ ret = xsplice_control(&op->u.xsplice);
+ copyback = 1;
+ break;
#ifdef HAS_PCI
case XEN_SYSCTL_pcitopoinfo:
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
new file mode 100644
index 0000000..e816394
--- /dev/null
+++ b/xen/common/xsplice.c
@@ -0,0 +1,405 @@
+/*
+ * xSplice - Copyright Oracle Corp. Inc 2015.
+ *
+ * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ */
+
+/* TODO: Sort includes .*/
+#include <xen/smp.h>
+#include <xen/keyhandler.h>
+#include <xen/spinlock.h>
+#include <xen/mm.h>
+#include <xen/list.h>
+#include <xen/guest_access.h>
+#include <xen/stdbool.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/xsplice.h>
+#include <public/sysctl.h>
+
+#include <asm/event.h>
+
+static DEFINE_SPINLOCK(payload_list_lock);
+static LIST_HEAD(payload_list);
+static unsigned int payload_cnt;
+static unsigned int payload_version = 1;
+static int _debug = 1;
+#define where() { if (_debug) printk("%s:%d\n", __func__, __LINE__); }
+
+struct payload {
+ char id[XEN_XSPLICE_ID_SIZE]; /* Unique id. */
+ int32_t status; /* XSPLICE_STATUS_* or Exx type value. */
+ int32_t old_status; /* XSPLICE_STATUS_* or Exx type value. */
+
+ uint32_t cmd; /* Action request. XSPLICE_ACTION_* */
+ struct spinlock cmd_lock; /* Lock against the action. */
+
+ uint8_t *raw; /* Pointer to Elf file. */
+ ssize_t size; /* Size of 'raw'. */
+
+ struct tasklet tasklet;
+ struct list_head list; /* Linked to 'payload_list'. */
+};
+
+static const char *status2str(int64_t status)
+{
+#define STATUS(x) [XSPLICE_STATUS_##x] = #x
+ static const char *const names[] = {
+ STATUS(LOADED),
+ STATUS(PROGRESS),
+ STATUS(CHECKED),
+ STATUS(APPLIED),
+ STATUS(REVERTED),
+ };
+
+ if (status >= ARRAY_SIZE(names))
+ return "unknown";
+
+ if (status < 0)
+ return "-EXX";
+
+ if (!names[status])
+ return "unknown";
+
+ return names[status];
+}
+
+void xsplice_printall(unsigned char key)
+{
+ struct payload *data;
+
+ spin_lock(&payload_list_lock);
+
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ printk(" id=%s status=%s(%d,old=%d): \n", data->id,
+ status2str(data->status), data->status, data->old_status);
+ }
+ spin_unlock(&payload_list_lock);
+}
+
+struct payload *find_payload(const char *id, bool_t need_lock)
+{
+ struct payload *data, *found = NULL;
+
+ if ( need_lock )
+ spin_lock(&payload_list_lock);
+
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ if ( !strncmp(data->id, id, XEN_XSPLICE_ID_SIZE) )
+ {
+ found = data;
+ break;
+ }
+ }
+
+ if ( need_lock )
+ spin_unlock(&payload_list_lock);
+
+ return found;
+}
+
+static int verify_payload(xen_sysctl_xsplice_upload_t *upload)
+{
+ if ( upload->id[0] == '\0' )
+ {
+ where();
+ return -EINVAL;
+ }
+ if ( upload->size == 0 )
+ {
+ where();
+ return -EINVAL;
+ }
+ if ( !guest_handle_okay(upload->payload, upload->size) )
+ {
+ where();
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+/*
+ * We MUST be holding the spinlock.
+ */
+static void __free_payload(struct payload *data)
+{
+
+ free_xenheap_pages(data->raw, get_order_from_bytes(data->size));
+ list_del(&data->list);
+ payload_cnt --;
+ payload_version ++;
+ tasklet_kill(&data->tasklet);
+ xfree(data);
+}
+#include <xen/delay.h>
+static void xsplice_tasklet(unsigned long _data)
+{
+ struct payload *data = (struct payload *)_data;
+
+ /* TODO: Remove it. */
+ mdelay(1000);
+
+ spin_lock(&data->cmd_lock);
+ switch ( data->cmd ) {
+ case XSPLICE_ACTION_CHECK:
+ /* Do the operation here. */
+ data->status = XSPLICE_STATUS_CHECKED;
+ break;
+ case XSPLICE_ACTION_APPLY:
+ /* TODO: Well, do the work :-) */
+ data->status = XSPLICE_STATUS_APPLIED;
+ break;
+ case XSPLICE_ACTION_REVERT:
+ /* TODO: Well, do the work :-) */
+ data->status = XSPLICE_STATUS_REVERTED;
+ break;
+ default:
+ data->status = -EINVAL;
+ }
+ spin_unlock(&data->cmd_lock);
+}
+
+static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
+{
+ struct payload *data;
+ uint8_t *raw = NULL;
+ int rc;
+
+ rc = verify_payload(upload);
+ if ( rc )
+ return rc;
+
+ /*
+ * Compute the size of the structures which need to be verified.
+ */
+
+ data = find_payload(upload->id, true);
+ if ( data )
+ {
+ where();
+ return -EEXIST;
+ }
+ rc = -ENOMEM;
+ data = xzalloc(struct payload);
+ if ( !data )
+ {
+ where();
+ return rc;
+ }
+
+ raw = alloc_xenheap_pages(get_order_from_bytes(upload->size), 0);
+ if ( !raw )
+ {
+ printk("%s: alloc for %ld bytes, %d order\n", __func__, upload->size, get_order_from_bytes(upload->size));
+ xfree(data);
+ return rc;
+ }
+ if ( copy_from_guest(raw, upload->payload, upload->size) )
+ {
+ rc = -EFAULT;
+ goto err_out;
+ }
+
+ printk("%s: size %ld %p [%02x %02x ..] \n", __func__, upload->size,
+ raw, (unsigned int)raw[0], (unsigned int)raw[1]);
+
+ /* TODO: Verify signature . */
+ memcpy(data->id, upload->id, XEN_XSPLICE_ID_SIZE);
+ data->status = XSPLICE_STATUS_LOADED;
+ INIT_LIST_HEAD(&data->list);
+ data->raw = raw;
+ data->size = upload->size;
+ spin_lock_init(&data->cmd_lock);
+ data->cmd = 0;
+ tasklet_init(&data->tasklet, xsplice_tasklet, (unsigned long)data);
+
+ spin_lock(&payload_list_lock);
+ list_add_tail(&data->list, &payload_list);
+ payload_cnt ++;
+ payload_version ++;
+ spin_unlock(&payload_list_lock);
+
+ return 0;
+
+ err_out:
+ if ( raw )
+ free_xenheap_pages(raw, get_order_from_bytes(upload->size));
+ if ( data )
+ xfree(data);
+ return rc;
+}
+
+static int xsplice_get(xen_sysctl_xsplice_summary_t *summary)
+{
+ struct payload *data;
+
+ if ( summary->status )
+ return -EINVAL;
+
+ data = find_payload(summary->id, true);
+ if ( !data )
+ return -ENOENT;
+
+ summary->status = data->status;
+
+ return 0;
+}
+
+static int xsplice_list(xen_sysctl_xsplice_list_t *list)
+{
+ xen_sysctl_xsplice_summary_t summary;
+ struct payload *data;
+ unsigned int idx = 0, i = 0;
+ int rc = 0;
+ unsigned int ver = payload_version;
+
+ // TODO: Increase to 64. Leave 4 for debug.
+ if ( list->nr > 4 )
+ return -E2BIG;
+
+ if ( guest_handle_is_null(list->summary) )
+ return -EINVAL;
+
+ spin_lock(&payload_list_lock);
+ if ( list->idx > payload_cnt )
+ {
+ spin_unlock(&payload_list_lock);
+ where();
+ return -EINVAL;
+ }
+
+ list_for_each_entry( data, &payload_list, list )
+ {
+ if ( list->idx > i++ )
+ continue;
+
+ /* Copy all of the bytes avoid leaking stack data. */
+ memcpy(summary.id, data->id, XEN_XSPLICE_ID_SIZE);
+ summary.status = data->status;
+
+ /* N.B. 'idx' != 'i'. */
+ if ( copy_to_guest_offset(list->summary, idx++, &summary, 1) )
+ {
+ rc = -EFAULT;
+ break;
+ }
+ if ( hypercall_preempt_check() || (idx + 1 > list->nr) )
+ {
+ break;
+ }
+ }
+ list->nr = payload_cnt - i; /* Remaining amount. */
+ spin_unlock(&payload_list_lock);
+ list->version = ver;
+
+ /* And how many we have processed. */
+ return rc ? rc : idx;
+}
+
+static int xsplice_action(xen_sysctl_xsplice_action_t *action)
+{
+ struct payload *data;
+ int rc = -EINVAL;
+
+ if ( action->id[0] == '\0' )
+ return rc;
+
+ spin_lock(&payload_list_lock);
+ data = find_payload(action->id, false /* we are holding the lock. */);
+ if ( !data )
+ {
+ rc = -ENOENT;
+ goto out;
+ }
+ if ( action->cmd != XSPLICE_ACTION_UNLOAD )
+ spin_lock(&data->cmd_lock);
+
+ switch ( action->cmd )
+ {
+ case XSPLICE_ACTION_CHECK:
+ if ( ( data->status == XSPLICE_STATUS_LOADED ) )
+ {
+ data->old_status = data->status;
+ data->status = XSPLICE_STATUS_PROGRESS;
+ data->cmd = action->cmd;
+ tasklet_schedule(&data->tasklet);
+ rc = 0;
+ } else if ( data->status == XSPLICE_STATUS_CHECKED )
+ {
+ rc = 0;
+ }
+ break;
+ case XSPLICE_ACTION_UNLOAD:
+ if ( ( data->status == XSPLICE_STATUS_REVERTED ) ||
+ ( data->status == XSPLICE_STATUS_LOADED ) ||
+ ( data->status == XSPLICE_STATUS_CHECKED ) )
+ {
+ __free_payload(data);
+ /* No touching 'data' from here on! */
+ rc = 0;
+ }
+ break;
+ case XSPLICE_ACTION_REVERT:
+ if ( data->status == XSPLICE_STATUS_APPLIED )
+ {
+ data->old_status = data->status;
+ data->status = XSPLICE_STATUS_PROGRESS;
+ data->cmd = action->cmd;
+ rc = 0;
+ /* TODO: Tasklet is not good for this. We need a different vehicle. */
+ tasklet_schedule(&data->tasklet);
+ }
+ break;
+ case XSPLICE_ACTION_APPLY:
+ if ( ( data->status == XSPLICE_STATUS_CHECKED ) ||
+ ( data->status == XSPLICE_STATUS_REVERTED ))
+ {
+ data->old_status = data->status;
+ data->status = XSPLICE_STATUS_PROGRESS;
+ data->cmd = action->cmd;
+ rc = 0;
+ /* TODO: Tasklet is not good for this. We need a different vehicle. */
+ tasklet_schedule(&data->tasklet);
+ }
+ break;
+ default:
+ rc = -ENOSYS;
+ break;
+ }
+
+ if ( action->cmd != XSPLICE_ACTION_UNLOAD )
+ spin_unlock(&data->cmd_lock);
+ out:
+ spin_unlock(&payload_list_lock);
+
+ return rc;
+}
+
+int xsplice_control(xen_sysctl_xsplice_op_t *xsplice)
+{
+ int rc;
+
+ switch ( xsplice->cmd )
+ {
+ case XEN_SYSCTL_XSPLICE_UPLOAD:
+ rc = xsplice_upload(&xsplice->u.upload);
+ break;
+ case XEN_SYSCTL_XSPLICE_GET:
+ rc = xsplice_get(&xsplice->u.get);
+ break;
+ case XEN_SYSCTL_XSPLICE_LIST:
+ rc = xsplice_list(&xsplice->u.list);
+ break;
+ case XEN_SYSCTL_XSPLICE_ACTION:
+ rc = xsplice_action(&xsplice->u.action);
+ break;
+ default:
+ rc = -ENOSYS;
+ break;
+ }
+
+ return rc;
+}
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 58c9be2..48dd511 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -710,6 +710,70 @@ struct xen_sysctl_psr_cat_op {
typedef struct xen_sysctl_psr_cat_op xen_sysctl_psr_cat_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_psr_cat_op_t);
+/*
+ * XEN_SYSCTL_XSPLICE_op
+ *
+ */
+#define XEN_SYSCTL_XSPLICE_UPLOAD 0
+#define XEN_XSPLICE_ID_SIZE 40
+
+struct xen_sysctl_xsplice_upload {
+ char id[XEN_XSPLICE_ID_SIZE]; /* IN, name of the patch. */
+ uint64_t size; /* IN, size of the ELF file. */
+ XEN_GUEST_HANDLE_64(uint8) payload; /* IN, the ELF file. */
+};
+typedef struct xen_sysctl_xsplice_upload xen_sysctl_xsplice_upload_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_upload_t);
+
+#define XEN_SYSCTL_XSPLICE_GET 1
+struct xen_sysctl_xsplice_summary {
+ char id[XEN_XSPLICE_ID_SIZE]; /* IN, name of the patch. */
+#define XSPLICE_STATUS_LOADED 0x01
+#define XSPLICE_STATUS_PROGRESS 0x02
+#define XSPLICE_STATUS_CHECKED 0x04
+#define XSPLICE_STATUS_APPLIED 0x08
+#define XSPLICE_STATUS_REVERTED 0x10
+ /* Any negative value is an error. The error would be in -EXX format. */
+ int32_t status; /* OUT, On IN has to be zero. */
+};
+typedef struct xen_sysctl_xsplice_summary xen_sysctl_xsplice_summary_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_summary_t);
+
+#define XEN_SYSCTL_XSPLICE_LIST 2
+struct xen_sysctl_xsplice_list {
+ uint32_t version; /* OUT. */
+ uint32_t idx; /* IN/OUT */
+ uint32_t nr; /* IN/OUT */
+ XEN_GUEST_HANDLE_64(xen_sysctl_xsplice_summary_t) summary; /* OUT */
+};
+typedef struct xen_sysctl_xsplice_list xen_sysctl_xsplice_list_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_list_t);
+
+#define XEN_SYSCTL_XSPLICE_ACTION 3
+struct xen_sysctl_xsplice_action {
+ char id[XEN_XSPLICE_ID_SIZE]; /* IN, name of the patch. */
+#define XSPLICE_ACTION_CHECK 1
+#define XSPLICE_ACTION_UNLOAD 2
+#define XSPLICE_ACTION_REVERT 3
+#define XSPLICE_ACTION_APPLY 4
+ uint32_t cmd; /* IN */
+ uint64_aligned_t time; /* IN */
+};
+typedef struct xen_sysctl_xsplice_action xen_sysctl_xsplice_action_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_action_t);
+
+struct xen_sysctl_xsplice_op {
+ uint32_t cmd; /* IN */
+ union {
+ xen_sysctl_xsplice_upload_t upload;
+ xen_sysctl_xsplice_list_t list;
+ xen_sysctl_xsplice_summary_t get;
+ xen_sysctl_xsplice_action_t action;
+ } u;
+};
+typedef struct xen_sysctl_xsplice_op xen_sysctl_xsplice_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_op_t);
+
struct xen_sysctl {
uint32_t cmd;
#define XEN_SYSCTL_readconsole 1
@@ -734,6 +798,7 @@ struct xen_sysctl {
#define XEN_SYSCTL_psr_cmt_op 21
#define XEN_SYSCTL_pcitopoinfo 22
#define XEN_SYSCTL_psr_cat_op 23
+#define XEN_SYSCTL_xsplice_op 24
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
@@ -758,6 +823,7 @@ struct xen_sysctl {
struct xen_sysctl_coverage_op coverage_op;
struct xen_sysctl_psr_cmt_op psr_cmt_op;
struct xen_sysctl_psr_cat_op psr_cat_op;
+ struct xen_sysctl_xsplice_op xsplice;
uint8_t pad[128];
} u;
};
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
new file mode 100644
index 0000000..41e28da
--- /dev/null
+++ b/xen/include/xen/xsplice.h
@@ -0,0 +1,9 @@
+#ifndef __XEN_XSPLICE_H__
+#define __XEN_XSPLICE_H__
+
+struct xen_sysctl_xsplice_op;
+int xsplice_control(struct xen_sysctl_xsplice_op *);
+
+extern void xsplice_printall(unsigned char key);
+
+#endif /* __XEN_XSPLICE_H__ */
--
1.8.4.2
^ permalink raw reply related [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
@ 2015-07-30 16:47 ` Johannes Erdfelt
2015-07-31 15:46 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 170+ messages in thread
From: Johannes Erdfelt @ 2015-07-30 16:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: elena.ufimtseva, jeremy, hanweidong, jbeulich, john.liuqiming,
paul.voccio, daniel.kiper, major.hayden, liuyingdong, aliguori,
xen-devel, steven.wilson, peter.huangpeng, msw, xiantao.zxt,
rick.harris, josh.kearney, jinsong.liu, amesserl, mpohlack,
dslutz, fanhenglong, Andrew.Cooper3
Thanks for the work on this. I had some comments and questions on the
latest draft.
On Mon, Jul 27, 2015, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> +#define XSPLICE_HOWTO_FLAG_PC_REL 0x1 /* Is PC relative. */
> +#define XSPLICE_HOWOT_FLAG_SIGN 0x2 /* Should the new value be treated as signed value. */
s/HOWOT/HOWTO/
> +struct xsplice_reloc_howto {
> + uint32_t howto; /* XSPLICE_HOWTO_* */
> + uint32_t flag; /* XSPLICE_HOWTO_FLAG_* */
> + uint32_t size; /* Size, in bytes, of the item to be relocated. */
> + uint32_t r_shift; /* The value the final relocation is shifted right by; used to drop unwanted data from the relocation. */
> + uint64_t mask; /* Bitmask for which parts of the instruction or data are replaced with the relocated value. */
> + uint8_t pad[8]; /* Must be zero. */
> +};
I'm curious how r_shift and mask are used. I'm familiar with x86 and
x86_64 and I'm not sure how these fit in. Is this to support other
architectures?
> +### Trampoline (e9 opcode)
> +
> +The e9 opcode used for jmpq uses a 32-bit signed displacement. That means
> +we are limited to up to 2GB of virtual address to place the new code
> +from the old code. That should not be a problem since Xen hypervisor has
> +a very small footprint.
> +
> +However if we need - we can always add two trampolines. One at the 2GB
> +limit that calls the next trampoline.
I'm not sure I understand the concern. At least on x86_64, there is a
ton of unused virtual address space where the hypervisor image is
mapped. Why not simply map memory at the end of virtual address space?
There shouldn't be a concern with 2GB jumps then.
> +Please note there is a small limitation for trampolines in
> +function entries: The target function (+ trailing padding) must be able
> +to accomodate the trampoline. On x86 with +-2 GB relative jumps,
> +this means 5 bytes are required.
> +
> +Depending on compiler settings, there are several functions in Xen that
> +are smaller (without inter-function padding).
> +
> +<pre>
> +readelf -sW xen-syms | grep " FUNC " | \
> + awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
> +
> +...
> +3 FUNC LOCAL wbinvd_ipi
> +3 FUNC LOCAL shadow_l1_index
> +...
> +</pre>
> +A compile-time check for, e.g., a minimum alignment of functions or a
> +runtime check that verifies symbol size (+ padding to next symbols) for
> +that in the hypervisor is advised.
Is this really necessary? The way Xen is currently compiled results in
functions being aligned at 16-byte boundaries. The extra space is padded
with NOPs. Even if a function is only 3 bytes, it still has at least 16
bytes of space to use.
This can be controlled with the -falign-functions option to gcc.
Also, there are ways to get a 5-byte NOP added before the function.
This is what the Linux kernel does for ftrace which is what the recent
Linux kernel live patching support is built on.
It seems like it would be easier to be explicit during the build process
than do runtime checks to ensure there is enough space.
> +### When to patch
> +
> +During the discussion on the design two candidates bubbled where
> +the call stack for each CPU would be deterministic. This would
> +minimize the chance of the patch not being applied due to safety
> +checks failing.
It would be nice to have the consistency model be more explicit.
Maybe using the terminology from this LKML post?
https://lkml.org/lkml/2014/11/7/354
> +To randezvous all the CPUs an barrier with an maximum timeout (which
> +could be adjusted), combined with forcing all other CPUs through the
> +hypervisor with IPIs, can be utilized to have all the CPUs be lockstep.
s/randezvous/rendezvous/
> +### Compiling the hypervisor code
> +
> +Hotpatch generation often requires support for compiling the target
> +with -ffunction-sections / -fdata-sections. Changes would have to
> +be done to the linker scripts to support this.
Is this for correctness reasons?
I understand this would be a good idea to reduce the size of patches,
but I wanted to make sure I'm not missing something.
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard. Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header files, and some C files are also compiled
> +multiple times and linked under different names (guest_walk.c).
I'm not sure I understand the problem with static symbols. They aren't
visible outside of the .c file, so when performing the linking against
the target xen image, there shouldn't be any conflicts.
JE
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1
2015-07-30 16:47 ` Johannes Erdfelt
@ 2015-07-31 15:46 ` Konrad Rzeszutek Wilk
2015-08-11 14:17 ` Jan Beulich
0 siblings, 1 reply; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-07-31 15:46 UTC (permalink / raw)
To: Johannes Erdfelt
Cc: elena.ufimtseva, jeremy, hanweidong, jbeulich, john.liuqiming,
paul.voccio, Konrad Rzeszutek Wilk, daniel.kiper, major.hayden,
liuyingdong, aliguori, xen-devel, steven.wilson, peter.huangpeng,
msw, xiantao.zxt, rick.harris, josh.kearney, jinsong.liu,
amesserl, mpohlack, dslutz, fanhenglong, Andrew.Cooper3
On Thu, Jul 30, 2015 at 09:47:40AM -0700, Johannes Erdfelt wrote:
> Thanks for the work on this. I had some comments and questions on the
> latest draft.
Hey Johannes!
Thank you for your review!
>
> On Mon, Jul 27, 2015, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > +#define XSPLICE_HOWTO_FLAG_PC_REL 0x1 /* Is PC relative. */
> > +#define XSPLICE_HOWOT_FLAG_SIGN 0x2 /* Should the new value be treated as signed value. */
>
> s/HOWOT/HOWTO/
>
> > +struct xsplice_reloc_howto {
> > + uint32_t howto; /* XSPLICE_HOWTO_* */
> > + uint32_t flag; /* XSPLICE_HOWTO_FLAG_* */
> > + uint32_t size; /* Size, in bytes, of the item to be relocated. */
> > + uint32_t r_shift; /* The value the final relocation is shifted right by; used to drop unwanted data from the relocation. */
> > + uint64_t mask; /* Bitmask for which parts of the instruction or data are replaced with the relocated value. */
> > + uint8_t pad[8]; /* Must be zero. */
> > +};
>
> I'm curious how r_shift and mask are used. I'm familiar with x86 and
> x86_64 and I'm not sure how these fit in. Is this to support other
> architectures?
It is to patch up data. We can specify the exact mask for an unsigned
int - so we only patch specific bits. Ditto if we want to remove certain
values.
>
> > +### Trampoline (e9 opcode)
> > +
> > +The e9 opcode used for jmpq uses a 32-bit signed displacement. That means
> > +we are limited to up to 2GB of virtual address to place the new code
> > +from the old code. That should not be a problem since Xen hypervisor has
> > +a very small footprint.
> > +
> > +However if we need - we can always add two trampolines. One at the 2GB
> > +limit that calls the next trampoline.
>
> I'm not sure I understand the concern. At least on x86_64, there is a
> ton of unused virtual address space where the hypervisor image is
> mapped. Why not simply map memory at the end of virtual address space?
>
> There shouldn't be a concern with 2GB jumps then.
Correct. This is added on if the hypervisor ends up gobbling up tons
of memory and having those virtual addresses eaten up.
>
> > +Please note there is a small limitation for trampolines in
> > +function entries: The target function (+ trailing padding) must be able
> > +to accomodate the trampoline. On x86 with +-2 GB relative jumps,
> > +this means 5 bytes are required.
> > +
> > +Depending on compiler settings, there are several functions in Xen that
> > +are smaller (without inter-function padding).
> > +
> > +<pre>
> > +readelf -sW xen-syms | grep " FUNC " | \
> > + awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
> > +
> > +...
> > +3 FUNC LOCAL wbinvd_ipi
> > +3 FUNC LOCAL shadow_l1_index
> > +...
> > +</pre>
> > +A compile-time check for, e.g., a minimum alignment of functions or a
> > +runtime check that verifies symbol size (+ padding to next symbols) for
> > +that in the hypervisor is advised.
>
> Is this really necessary? The way Xen is currently compiled results in
> functions being aligned at 16-byte boundaries. The extra space is padded
> with NOPs. Even if a function is only 3 bytes, it still has at least 16
> bytes of space to use.
>
> This can be controlled with the -falign-functions option to gcc.
Right. The 'compile-time' check can be just to make sure that the
compiler is controlled by that - otherwise we will halt the compilation.
>
> Also, there are ways to get a 5-byte NOP added before the function.
> This is what the Linux kernel does for ftrace which is what the recent
> Linux kernel live patching support is built on.
>
> It seems like it would be easier to be explicit during the build process
> than do runtime checks to ensure there is enough space.
Correct.
>
> > +### When to patch
> > +
> > +During the discussion on the design two candidates bubbled where
> > +the call stack for each CPU would be deterministic. This would
> > +minimize the chance of the patch not being applied due to safety
> > +checks failing.
>
> It would be nice to have the consistency model be more explicit.
>
> Maybe using the terminology from this LKML post?
>
> https://lkml.org/lkml/2014/11/7/354
Certainy we can borrow.
>
> > +To randezvous all the CPUs an barrier with an maximum timeout (which
> > +could be adjusted), combined with forcing all other CPUs through the
> > +hypervisor with IPIs, can be utilized to have all the CPUs be lockstep.
>
> s/randezvous/rendezvous/
>
> > +### Compiling the hypervisor code
> > +
> > +Hotpatch generation often requires support for compiling the target
> > +with -ffunction-sections / -fdata-sections. Changes would have to
> > +be done to the linker scripts to support this.
>
> Is this for correctness reasons?
Sanity mostly. Without that having the objdump and tools to figure out
what piece of code is for what would be complicated.
>
> I understand this would be a good idea to reduce the size of patches,
> but I wanted to make sure I'm not missing something.
>
> > +### Symbol names
> > +
> > +
> > +Xen as it is now, has a couple of non-unique symbol names which will
> > +make runtime symbol identification hard. Sometimes, static symbols
> > +simply have the same name in C files, sometimes such symbols get
> > +included via header files, and some C files are also compiled
> > +multiple times and linked under different names (guest_walk.c).
>
> I'm not sure I understand the problem with static symbols. They aren't
> visible outside of the .c file, so when performing the linking against
> the target xen image, there shouldn't be any conflicts.
To do run-time checking based on symbols. We may get information that
we need to patch 'xen_someting_static+<0x1f>' and we have not been supplied
the virtual address. As such if xen_something_static may not
show up at all - and we can't patch it. We need some mechanism to
tweak the build so that those symbols do bubble up.
>
> JE
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1
2015-07-31 15:46 ` Konrad Rzeszutek Wilk
@ 2015-08-11 14:17 ` Jan Beulich
0 siblings, 0 replies; 170+ messages in thread
From: Jan Beulich @ 2015-08-11 14:17 UTC (permalink / raw)
To: Johannes Erdfelt, Konrad Rzeszutek Wilk
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
mpohlack, dslutz, fanhenglong, Andrew.Cooper3
>>> On 31.07.15 at 17:46, <konrad.wilk@oracle.com> wrote:
> On Thu, Jul 30, 2015 at 09:47:40AM -0700, Johannes Erdfelt wrote:
>> On Mon, Jul 27, 2015, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
>> > +struct xsplice_reloc_howto {
>> > + uint32_t howto; /* XSPLICE_HOWTO_* */
>> > + uint32_t flag; /* XSPLICE_HOWTO_FLAG_* */
>> > + uint32_t size; /* Size, in bytes, of the item to be relocated. */
>> > + uint32_t r_shift; /* The value the final relocation is shifted right by; used to drop unwanted data from the relocation. */
>> > + uint64_t mask; /* Bitmask for which parts of the instruction or data are replaced with the relocated value. */
>> > + uint8_t pad[8]; /* Must be zero. */
>> > +};
>>
>> I'm curious how r_shift and mask are used. I'm familiar with x86 and
>> x86_64 and I'm not sure how these fit in. Is this to support other
>> architectures?
>
> It is to patch up data. We can specify the exact mask for an unsigned
> int - so we only patch specific bits. Ditto if we want to remove certain
> values.
Still I don't see a practical use: What relocated item would (on x86)
be stored starting at other than bit 0 of a byte/word? Also, wouldn't
a shift count be redundant with the mask value anyway?
Jan
^ permalink raw reply [flat|nested] 170+ messages in thread
* [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-07-27 19:20 [RFC PATCH v3.1] xSplice design Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
@ 2015-07-27 19:20 ` Konrad Rzeszutek Wilk
2015-07-28 15:51 ` Andrew Cooper
` (2 more replies)
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
2 siblings, 3 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-07-27 19:20 UTC (permalink / raw)
To: xen-devel, msw, aliguori, amesserl, rick.harris, paul.voccio,
steven.wilson, major.hayden, josh.kearney, jinsong.liu,
xiantao.zxt, daniel.kiper, elena.ufimtseva, bob.liu, hanweidong,
peter.huangpeng, fanhenglong, liuyingdong, john.liuqiming,
jbeulich, Andrew.Cooper3, jeremy, dslutz, mpohlack
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
tools/libxc/xc_private.c | 3 +++
tools/misc/xen-xsplice.c | 25 +++++++++++++++++++++++++
xen/common/kernel.c | 11 +++++++++++
xen/common/version.c | 5 +++++
xen/include/public/version.h | 4 ++++
xen/include/xen/compile.h.in | 1 +
xen/include/xen/version.h | 1 +
7 files changed, 50 insertions(+)
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index 2ffebd9..7c039ca 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -713,6 +713,9 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
case XENVER_commandline:
sz = sizeof(xen_commandline_t);
break;
+ case XENVER_build_id:
+ sz = sizeof(xen_build_id_t);
+ break;
default:
ERROR("xc_version: unknown command %d\n", cmd);
return -EINVAL;
diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
index 7cf9879..dd8266c 100644
--- a/tools/misc/xen-xsplice.c
+++ b/tools/misc/xen-xsplice.c
@@ -17,6 +17,7 @@ void show_help(void)
" <id> An unique name of payload. Up to 40 characters.\n"
"Commands:\n"
" help display this help\n"
+ " build-id display build-id of hypervisor.\n"
" upload <id> <file> upload file <cpuid> with <id> name\n"
" list list payloads uploaded.\n"
" apply <id> apply <id> patch.\n"
@@ -306,12 +307,36 @@ int action_func(int argc, char *argv[], unsigned int idx)
return rc;
}
+
+static int build_id_func(int argc, char *argv[])
+{
+ xen_build_id_t build_id;
+
+ if ( argc )
+ {
+ show_help();
+ return -1;
+ }
+
+ memset(build_id, 0, sizeof(*build_id));
+
+ if ( xc_version(xch, XENVER_build_id, &build_id) < 0 )
+ {
+ printf("Failed to get build_id: %d(%s)\n", errno, strerror(errno));
+ return -1;
+ }
+
+ printf("%s\n", build_id);
+ return 0;
+}
+
struct {
const char *name;
int (*function)(int argc, char *argv[]);
} main_options[] = {
{ "help", help_func },
{ "list", list_func },
+ { "build-id", build_id_func },
{ "upload", upload_func },
};
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 6a3196a..e9d41b6 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -357,6 +357,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
return -EFAULT;
return 0;
+
+ case XENVER_build_id:
+ {
+ xen_build_id_t build_id;
+
+ memset(build_id, 0, sizeof(build_id));
+ safe_strcpy(build_id, xen_build_id());
+ if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
+ return -EFAULT;
+ return 0;
+ }
}
return -ENOSYS;
diff --git a/xen/common/version.c b/xen/common/version.c
index b152e27..5c3dbb0 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -55,3 +55,8 @@ const char *xen_banner(void)
{
return XEN_BANNER;
}
+
+const char *xen_build_id(void)
+{
+ return XEN_BUILD_ID;
+}
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 44f26b0..c863393 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -83,6 +83,10 @@ typedef struct xen_feature_info xen_feature_info_t;
#define XENVER_commandline 9
typedef char xen_commandline_t[1024];
+#define XENVER_build_id 10
+typedef char xen_build_id_t[1024];
+#define XEN_BUILD_ID_LEN (sizeof(xen_build_id_t))
+
#endif /* __XEN_PUBLIC_VERSION_H__ */
/*
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 440ecb2..939685e 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -10,4 +10,5 @@
#define XEN_EXTRAVERSION "@@extraversion@@"
#define XEN_CHANGESET "@@changeset@@"
+#define XEN_BUILD_ID "@@changeset@@"
#define XEN_BANNER \
diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
index 81a3c7d..02f9585 100644
--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -12,5 +12,6 @@ unsigned int xen_minor_version(void);
const char *xen_extra_version(void);
const char *xen_changeset(void);
const char *xen_banner(void);
+const char *xen_build_id(void);
#endif /* __XEN_VERSION_H__ */
--
1.8.4.2
^ permalink raw reply related [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
@ 2015-07-28 15:51 ` Andrew Cooper
2015-07-28 16:35 ` Konrad Rzeszutek Wilk
2015-08-05 8:50 ` Martin Pohlack
2015-08-11 14:02 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Jan Beulich
2 siblings, 1 reply; 170+ messages in thread
From: Andrew Cooper @ 2015-07-28 15:51 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel, msw, aliguori, amesserl,
rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz, mpohlack
On 27/07/15 20:20, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
> index 440ecb2..939685e 100644
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -10,4 +10,5 @@
> #define XEN_EXTRAVERSION "@@extraversion@@"
>
> #define XEN_CHANGESET "@@changeset@@"
> +#define XEN_BUILD_ID "@@changeset@@"
I am not sure putting the changeset into the build id field is sensible.
On the other hand, linking .note.gnu.build-id and exposing it as
XENVER_build_id seems like a very sensible thing to do. It would
probably make sense to expose it in `xl info`.
~Andrew
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-07-28 15:51 ` Andrew Cooper
@ 2015-07-28 16:35 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-07-28 16:35 UTC (permalink / raw)
To: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz, mpohlack
On July 28, 2015 11:51:00 AM EDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 27/07/15 20:20, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/include/xen/compile.h.in
>b/xen/include/xen/compile.h.in
>> index 440ecb2..939685e 100644
>> --- a/xen/include/xen/compile.h.in
>> +++ b/xen/include/xen/compile.h.in
>> @@ -10,4 +10,5 @@
>> #define XEN_EXTRAVERSION "@@extraversion@@"
>>
>> #define XEN_CHANGESET "@@changeset@@"
>> +#define XEN_BUILD_ID "@@changeset@@"
>
>I am not sure putting the changeset into the build id field is
>sensible.
>
Correct, it is unfinished.
>On the other hand, linking .note.gnu.build-id and exposing it as
>XENVER_build_id seems like a very sensible thing to do. It would
>probably make sense to expose it in `xl info`.
That can certainly be done.
>
>~Andrew
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
2015-07-28 15:51 ` Andrew Cooper
@ 2015-08-05 8:50 ` Martin Pohlack
2015-08-05 8:58 ` Andrew Cooper
2015-08-11 14:02 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Jan Beulich
2 siblings, 1 reply; 170+ messages in thread
From: Martin Pohlack @ 2015-08-05 8:50 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel, msw, aliguori, amesserl,
rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich,
Andrew.Cooper3, jeremy, dslutz
On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> tools/libxc/xc_private.c | 3 +++
> tools/misc/xen-xsplice.c | 25 +++++++++++++++++++++++++
> xen/common/kernel.c | 11 +++++++++++
> xen/common/version.c | 5 +++++
> xen/include/public/version.h | 4 ++++
> xen/include/xen/compile.h.in | 1 +
> xen/include/xen/version.h | 1 +
> 7 files changed, 50 insertions(+)
>
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 2ffebd9..7c039ca 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -713,6 +713,9 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
> case XENVER_commandline:
> sz = sizeof(xen_commandline_t);
> break;
> + case XENVER_build_id:
> + sz = sizeof(xen_build_id_t);
> + break;
> default:
> ERROR("xc_version: unknown command %d\n", cmd);
> return -EINVAL;
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> index 7cf9879..dd8266c 100644
> --- a/tools/misc/xen-xsplice.c
> +++ b/tools/misc/xen-xsplice.c
> @@ -17,6 +17,7 @@ void show_help(void)
> " <id> An unique name of payload. Up to 40 characters.\n"
> "Commands:\n"
> " help display this help\n"
> + " build-id display build-id of hypervisor.\n"
> " upload <id> <file> upload file <cpuid> with <id> name\n"
> " list list payloads uploaded.\n"
> " apply <id> apply <id> patch.\n"
> @@ -306,12 +307,36 @@ int action_func(int argc, char *argv[], unsigned int idx)
>
> return rc;
> }
> +
> +static int build_id_func(int argc, char *argv[])
> +{
> + xen_build_id_t build_id;
> +
> + if ( argc )
> + {
> + show_help();
> + return -1;
> + }
> +
> + memset(build_id, 0, sizeof(*build_id));
> +
> + if ( xc_version(xch, XENVER_build_id, &build_id) < 0 )
> + {
> + printf("Failed to get build_id: %d(%s)\n", errno, strerror(errno));
> + return -1;
> + }
> +
> + printf("%s\n", build_id);
> + return 0;
> +}
> +
> struct {
> const char *name;
> int (*function)(int argc, char *argv[]);
> } main_options[] = {
> { "help", help_func },
> { "list", list_func },
> + { "build-id", build_id_func },
> { "upload", upload_func },
> };
>
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index 6a3196a..e9d41b6 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -357,6 +357,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> return -EFAULT;
> return 0;
> +
> + case XENVER_build_id:
> + {
> + xen_build_id_t build_id;
> +
> + memset(build_id, 0, sizeof(build_id));
> + safe_strcpy(build_id, xen_build_id());
You seem to want to store and transfer the build_id as a string. Any
reason why we don't directly expose the build_id embedded by the linker
in binary format?
> + if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
> + return -EFAULT;
> + return 0;
> + }
We should not expose the build_id to normal guests, but only to Dom0.
A build_id uniquely identifies a specific build and I don't see how that
information would be required from DomU. It might actually help an
attacker to build his return-oriented programming exploit against a
specific build.
The normal version numbers should be enough to know about capabilities
and API.
> }
>
> return -ENOSYS;
> diff --git a/xen/common/version.c b/xen/common/version.c
> index b152e27..5c3dbb0 100644
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -55,3 +55,8 @@ const char *xen_banner(void)
> {
> return XEN_BANNER;
> }
> +
> +const char *xen_build_id(void)
> +{
> + return XEN_BUILD_ID;
> +}
> diff --git a/xen/include/public/version.h b/xen/include/public/version.h
> index 44f26b0..c863393 100644
> --- a/xen/include/public/version.h
> +++ b/xen/include/public/version.h
> @@ -83,6 +83,10 @@ typedef struct xen_feature_info xen_feature_info_t;
> #define XENVER_commandline 9
> typedef char xen_commandline_t[1024];
>
> +#define XENVER_build_id 10
> +typedef char xen_build_id_t[1024];
> +#define XEN_BUILD_ID_LEN (sizeof(xen_build_id_t))
> +
> #endif /* __XEN_PUBLIC_VERSION_H__ */
>
> /*
> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
> index 440ecb2..939685e 100644
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -10,4 +10,5 @@
> #define XEN_EXTRAVERSION "@@extraversion@@"
>
> #define XEN_CHANGESET "@@changeset@@"
> +#define XEN_BUILD_ID "@@changeset@@"
That leads to a chicken and egg problem when embedding a real build_id.
Some linker script magic seems to be required. I will try to refine
the patch.
> #define XEN_BANNER \
> diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
> index 81a3c7d..02f9585 100644
> --- a/xen/include/xen/version.h
> +++ b/xen/include/xen/version.h
> @@ -12,5 +12,6 @@ unsigned int xen_minor_version(void);
> const char *xen_extra_version(void);
> const char *xen_changeset(void);
> const char *xen_banner(void);
> +const char *xen_build_id(void);
>
> #endif /* __XEN_VERSION_H__ */
>
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-08-05 8:50 ` Martin Pohlack
@ 2015-08-05 8:58 ` Andrew Cooper
2015-08-05 13:27 ` Martin Pohlack
0 siblings, 1 reply; 170+ messages in thread
From: Andrew Cooper @ 2015-08-05 8:58 UTC (permalink / raw)
To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz
On 05/08/15 09:50, Martin Pohlack wrote:
> On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>> tools/libxc/xc_private.c | 3 +++
>> tools/misc/xen-xsplice.c | 25 +++++++++++++++++++++++++
>> xen/common/kernel.c | 11 +++++++++++
>> xen/common/version.c | 5 +++++
>> xen/include/public/version.h | 4 ++++
>> xen/include/xen/compile.h.in | 1 +
>> xen/include/xen/version.h | 1 +
>> 7 files changed, 50 insertions(+)
>>
>> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
>> index 2ffebd9..7c039ca 100644
>> --- a/tools/libxc/xc_private.c
>> +++ b/tools/libxc/xc_private.c
>> @@ -713,6 +713,9 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
>> case XENVER_commandline:
>> sz = sizeof(xen_commandline_t);
>> break;
>> + case XENVER_build_id:
>> + sz = sizeof(xen_build_id_t);
>> + break;
>> default:
>> ERROR("xc_version: unknown command %d\n", cmd);
>> return -EINVAL;
>> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
>> index 7cf9879..dd8266c 100644
>> --- a/tools/misc/xen-xsplice.c
>> +++ b/tools/misc/xen-xsplice.c
>> @@ -17,6 +17,7 @@ void show_help(void)
>> " <id> An unique name of payload. Up to 40 characters.\n"
>> "Commands:\n"
>> " help display this help\n"
>> + " build-id display build-id of hypervisor.\n"
>> " upload <id> <file> upload file <cpuid> with <id> name\n"
>> " list list payloads uploaded.\n"
>> " apply <id> apply <id> patch.\n"
>> @@ -306,12 +307,36 @@ int action_func(int argc, char *argv[], unsigned int idx)
>>
>> return rc;
>> }
>> +
>> +static int build_id_func(int argc, char *argv[])
>> +{
>> + xen_build_id_t build_id;
>> +
>> + if ( argc )
>> + {
>> + show_help();
>> + return -1;
>> + }
>> +
>> + memset(build_id, 0, sizeof(*build_id));
>> +
>> + if ( xc_version(xch, XENVER_build_id, &build_id) < 0 )
>> + {
>> + printf("Failed to get build_id: %d(%s)\n", errno, strerror(errno));
>> + return -1;
>> + }
>> +
>> + printf("%s\n", build_id);
>> + return 0;
>> +}
>> +
>> struct {
>> const char *name;
>> int (*function)(int argc, char *argv[]);
>> } main_options[] = {
>> { "help", help_func },
>> { "list", list_func },
>> + { "build-id", build_id_func },
>> { "upload", upload_func },
>> };
>>
>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>> index 6a3196a..e9d41b6 100644
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -357,6 +357,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
>> return -EFAULT;
>> return 0;
>> +
>> + case XENVER_build_id:
>> + {
>> + xen_build_id_t build_id;
>> +
>> + memset(build_id, 0, sizeof(build_id));
>> + safe_strcpy(build_id, xen_build_id());
> You seem to want to store and transfer the build_id as a string. Any
> reason why we don't directly expose the build_id embedded by the linker
> in binary format?
>
>> + if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
>> + return -EFAULT;
>> + return 0;
>> + }
> We should not expose the build_id to normal guests, but only to Dom0.
>
> A build_id uniquely identifies a specific build and I don't see how that
> information would be required from DomU. It might actually help an
> attacker to build his return-oriented programming exploit against a
> specific build.
>
> The normal version numbers should be enough to know about capabilities
> and API.
It will need its own XSM hook, but need not be strictly limited to just
dom0.
>
>> }
>>
>> return -ENOSYS;
>> diff --git a/xen/common/version.c b/xen/common/version.c
>> index b152e27..5c3dbb0 100644
>> --- a/xen/common/version.c
>> +++ b/xen/common/version.c
>> @@ -55,3 +55,8 @@ const char *xen_banner(void)
>> {
>> return XEN_BANNER;
>> }
>> +
>> +const char *xen_build_id(void)
>> +{
>> + return XEN_BUILD_ID;
>> +}
>> diff --git a/xen/include/public/version.h b/xen/include/public/version.h
>> index 44f26b0..c863393 100644
>> --- a/xen/include/public/version.h
>> +++ b/xen/include/public/version.h
>> @@ -83,6 +83,10 @@ typedef struct xen_feature_info xen_feature_info_t;
>> #define XENVER_commandline 9
>> typedef char xen_commandline_t[1024];
>>
>> +#define XENVER_build_id 10
>> +typedef char xen_build_id_t[1024];
>> +#define XEN_BUILD_ID_LEN (sizeof(xen_build_id_t))
>> +
>> #endif /* __XEN_PUBLIC_VERSION_H__ */
>>
>> /*
>> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
>> index 440ecb2..939685e 100644
>> --- a/xen/include/xen/compile.h.in
>> +++ b/xen/include/xen/compile.h.in
>> @@ -10,4 +10,5 @@
>> #define XEN_EXTRAVERSION "@@extraversion@@"
>>
>> #define XEN_CHANGESET "@@changeset@@"
>> +#define XEN_BUILD_ID "@@changeset@@"
> That leads to a chicken and egg problem when embedding a real build_id.
> Some linker script magic seems to be required. I will try to refine
> the patch.
So funnily enough, I tried experimenting with this and it is fairly easy
to get the basics done.
Further TODO which I havn't done yet is make the --build-id optional on
finding a compatible `ld`, and some symbol magic to directly locate
.note.gnu.build-id
However, this in addition to some of Konrad's original patch is a good
start.
~Andrew
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f24951..10938b2 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -112,7 +112,7 @@ $(TARGET)-syms: prelink.o xen.lds
$(BASEDIR)/common/symbols-dummy.o
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..46e6546 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -68,6 +68,13 @@ SECTIONS
} :text
. = ALIGN(SMP_CACHE_BYTES);
+ .notes : {
+ __start_notes = .;
+ *(.note.*)
+ __end_notes = .;
+ } :text
+
+ . = ALIGN(SMP_CACHE_BYTES);
.data.read_mostly : {
/* Exception table */
__start___ex_table = .;
^ permalink raw reply related [flat|nested] 170+ messages in thread* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-08-05 8:58 ` Andrew Cooper
@ 2015-08-05 13:27 ` Martin Pohlack
2015-08-05 14:06 ` (no subject) Martin Pohlack
2015-08-05 14:09 ` [PATCH] xsplice: Use ld-embedded build-ids Martin Pohlack
0 siblings, 2 replies; 170+ messages in thread
From: Martin Pohlack @ 2015-08-05 13:27 UTC (permalink / raw)
To: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz
On 05.08.2015 10:58, Andrew Cooper wrote:
> On 05/08/15 09:50, Martin Pohlack wrote:
>> On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>> tools/libxc/xc_private.c | 3 +++
>>> tools/misc/xen-xsplice.c | 25 +++++++++++++++++++++++++
>>> xen/common/kernel.c | 11 +++++++++++
>>> xen/common/version.c | 5 +++++
>>> xen/include/public/version.h | 4 ++++
>>> xen/include/xen/compile.h.in | 1 +
>>> xen/include/xen/version.h | 1 +
>>> 7 files changed, 50 insertions(+)
>>>
>>> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
>>> index 2ffebd9..7c039ca 100644
>>> --- a/tools/libxc/xc_private.c
>>> +++ b/tools/libxc/xc_private.c
>>> @@ -713,6 +713,9 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
>>> case XENVER_commandline:
>>> sz = sizeof(xen_commandline_t);
>>> break;
>>> + case XENVER_build_id:
>>> + sz = sizeof(xen_build_id_t);
>>> + break;
>>> default:
>>> ERROR("xc_version: unknown command %d\n", cmd);
>>> return -EINVAL;
>>> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
>>> index 7cf9879..dd8266c 100644
>>> --- a/tools/misc/xen-xsplice.c
>>> +++ b/tools/misc/xen-xsplice.c
>>> @@ -17,6 +17,7 @@ void show_help(void)
>>> " <id> An unique name of payload. Up to 40 characters.\n"
>>> "Commands:\n"
>>> " help display this help\n"
>>> + " build-id display build-id of hypervisor.\n"
>>> " upload <id> <file> upload file <cpuid> with <id> name\n"
>>> " list list payloads uploaded.\n"
>>> " apply <id> apply <id> patch.\n"
>>> @@ -306,12 +307,36 @@ int action_func(int argc, char *argv[], unsigned int idx)
>>>
>>> return rc;
>>> }
>>> +
>>> +static int build_id_func(int argc, char *argv[])
>>> +{
>>> + xen_build_id_t build_id;
>>> +
>>> + if ( argc )
>>> + {
>>> + show_help();
>>> + return -1;
>>> + }
>>> +
>>> + memset(build_id, 0, sizeof(*build_id));
>>> +
>>> + if ( xc_version(xch, XENVER_build_id, &build_id) < 0 )
>>> + {
>>> + printf("Failed to get build_id: %d(%s)\n", errno, strerror(errno));
>>> + return -1;
>>> + }
>>> +
>>> + printf("%s\n", build_id);
>>> + return 0;
>>> +}
>>> +
>>> struct {
>>> const char *name;
>>> int (*function)(int argc, char *argv[]);
>>> } main_options[] = {
>>> { "help", help_func },
>>> { "list", list_func },
>>> + { "build-id", build_id_func },
>>> { "upload", upload_func },
>>> };
>>>
>>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>>> index 6a3196a..e9d41b6 100644
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -357,6 +357,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
>>> return -EFAULT;
>>> return 0;
>>> +
>>> + case XENVER_build_id:
>>> + {
>>> + xen_build_id_t build_id;
>>> +
>>> + memset(build_id, 0, sizeof(build_id));
>>> + safe_strcpy(build_id, xen_build_id());
>> You seem to want to store and transfer the build_id as a string. Any
>> reason why we don't directly expose the build_id embedded by the linker
>> in binary format?
>>
>>> + if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
>>> + return -EFAULT;
>>> + return 0;
>>> + }
>> We should not expose the build_id to normal guests, but only to Dom0.
>>
>> A build_id uniquely identifies a specific build and I don't see how that
>> information would be required from DomU. It might actually help an
>> attacker to build his return-oriented programming exploit against a
>> specific build.
>>
>> The normal version numbers should be enough to know about capabilities
>> and API.
>
> It will need its own XSM hook, but need not be strictly limited to just
> dom0.
>
>>
>>> }
>>>
>>> return -ENOSYS;
>>> diff --git a/xen/common/version.c b/xen/common/version.c
>>> index b152e27..5c3dbb0 100644
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -55,3 +55,8 @@ const char *xen_banner(void)
>>> {
>>> return XEN_BANNER;
>>> }
>>> +
>>> +const char *xen_build_id(void)
>>> +{
>>> + return XEN_BUILD_ID;
>>> +}
>>> diff --git a/xen/include/public/version.h b/xen/include/public/version.h
>>> index 44f26b0..c863393 100644
>>> --- a/xen/include/public/version.h
>>> +++ b/xen/include/public/version.h
>>> @@ -83,6 +83,10 @@ typedef struct xen_feature_info xen_feature_info_t;
>>> #define XENVER_commandline 9
>>> typedef char xen_commandline_t[1024];
>>>
>>> +#define XENVER_build_id 10
>>> +typedef char xen_build_id_t[1024];
>>> +#define XEN_BUILD_ID_LEN (sizeof(xen_build_id_t))
>>> +
>>> #endif /* __XEN_PUBLIC_VERSION_H__ */
>>>
>>> /*
>>> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
>>> index 440ecb2..939685e 100644
>>> --- a/xen/include/xen/compile.h.in
>>> +++ b/xen/include/xen/compile.h.in
>>> @@ -10,4 +10,5 @@
>>> #define XEN_EXTRAVERSION "@@extraversion@@"
>>>
>>> #define XEN_CHANGESET "@@changeset@@"
>>> +#define XEN_BUILD_ID "@@changeset@@"
>> That leads to a chicken and egg problem when embedding a real build_id.
>> Some linker script magic seems to be required. I will try to refine
>> the patch.
>
> So funnily enough, I tried experimenting with this and it is fairly easy
> to get the basics done.
>
> Further TODO which I havn't done yet is make the --build-id optional on
> finding a compatible `ld`, and some symbol magic to directly locate
> .note.gnu.build-id
>
> However, this in addition to some of Konrad's original patch is a good
> start.
>
> ~Andrew
>
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 5f24951..10938b2 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -112,7 +112,7 @@ $(TARGET)-syms: prelink.o xen.lds
> $(BASEDIR)/common/symbols-dummy.o
> $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> $(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
> $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> - $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> + $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id \
> $(@D)/.$(@F).1.o -o $@
> rm -f $(@D)/.$(@F).[0-9]*
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 6553cff..46e6546 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -68,6 +68,13 @@ SECTIONS
> } :text
>
> . = ALIGN(SMP_CACHE_BYTES);
> + .notes : {
> + __start_notes = .;
> + *(.note.*)
> + __end_notes = .;
> + } :text
> +
> + . = ALIGN(SMP_CACHE_BYTES);
> .data.read_mostly : {
> /* Exception table */
> __start___ex_table = .;
And here is my version, also on-top of Konrad's series:
----------------------------------------------------------------------
[PATCH] xsplice: Use ld-embedded build-ids
Todo:
* Should be moved to sysctl to only allow Dom0 access
* Maybe convert to binary transport to userland instead of printable form
* use ld to actually embed the build ID
* convert to textual representation in hypervisor and report in
printable form
Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
---
xen/arch/x86/Makefile | 4 ++--
xen/arch/x86/xen.lds.S | 5 +++++
xen/common/kernel.c | 33 +++++++++++++++++++++++++++++----
xen/common/version.c | 5 -----
xen/include/xen/compile.h.in | 1 -
5 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f24951..f724bd8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -108,11 +108,11 @@ $(TARGET)-syms: prelink.o xen.lds
$(BASEDIR)/common/symbols-dummy.o
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..2176782 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -67,6 +67,11 @@ SECTIONS
*(.rodata.*)
} :text
+ .note.gnu.build-id : {
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ } :text
+
. = ALIGN(SMP_CACHE_BYTES);
.data.read_mostly : {
/* Exception table */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index e9d41b6..9814585 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -6,9 +6,11 @@
#include <xen/init.h>
#include <xen/lib.h>
+#include <xen/elf.h>
#include <xen/errno.h>
#include <xen/version.h>
#include <xen/sched.h>
+#include <xen/types.h>
#include <xen/paging.h>
#include <xen/nmi.h>
#include <xen/guest_access.h>
@@ -227,6 +229,10 @@ void __init do_initcalls(void)
* Simple hypercalls.
*/
+#define NT_GNU_BUILD_ID 3
+
+extern char * __note_gnu_build_id_start; /* defined in linker script */
+
DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
switch ( cmd )
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_build_id:
{
- xen_build_id_t build_id;
+ xen_build_id_t ascii_id;
+ Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
+ char * binary_id;
+ int i;
+
+ memset(ascii_id, 0, sizeof(ascii_id));
+
+ /* check if we really have a build-id */
+ if ( NT_GNU_BUILD_ID != n->type )
+ return 0;
+
+ /* sanity check, name should be "GNU" for ld-generated build-id */
+ if ( 0 != strncmp(ELFNOTE_NAME(n), "GNU", n->namesz))
+ return 0;
+
+ binary_id = (char *)ELFNOTE_DESC(n);
+
+ /* convert to printable format */
+ for (i = 0; i < n->descsz && (i + 1) * 2 <
sizeof(xen_build_id_t); i++)
+ {
+ snprintf(&ascii_id[i * 2], 3, "%02hhx", binary_id[i]);
+ }
- memset(build_id, 0, sizeof(build_id));
- safe_strcpy(build_id, xen_build_id());
- if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
+ if ( copy_to_guest(arg, ascii_id, ARRAY_SIZE(ascii_id)) )
return -EFAULT;
return 0;
}
diff --git a/xen/common/version.c b/xen/common/version.c
index 5c3dbb0..b152e27 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -55,8 +55,3 @@ const char *xen_banner(void)
{
return XEN_BANNER;
}
-
-const char *xen_build_id(void)
-{
- return XEN_BUILD_ID;
-}
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 939685e..440ecb2 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -10,5 +10,4 @@
#define XEN_EXTRAVERSION "@@extraversion@@"
#define XEN_CHANGESET "@@changeset@@"
-#define XEN_BUILD_ID "@@changeset@@"
#define XEN_BANNER \
--
2.5.0
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply related [flat|nested] 170+ messages in thread* (no subject)
2015-08-05 13:27 ` Martin Pohlack
@ 2015-08-05 14:06 ` Martin Pohlack
2015-08-05 14:09 ` [PATCH] xsplice: Use ld-embedded build-ids Martin Pohlack
1 sibling, 0 replies; 170+ messages in thread
From: Martin Pohlack @ 2015-08-05 14:06 UTC (permalink / raw)
To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz, Bjoern Doebel
Sending again without MUA-mangled patch.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 170+ messages in thread
* [PATCH] xsplice: Use ld-embedded build-ids
2015-08-05 13:27 ` Martin Pohlack
2015-08-05 14:06 ` (no subject) Martin Pohlack
@ 2015-08-05 14:09 ` Martin Pohlack
2015-08-11 14:12 ` Jan Beulich
1 sibling, 1 reply; 170+ messages in thread
From: Martin Pohlack @ 2015-08-05 14:09 UTC (permalink / raw)
To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz, Bjoern Doebel
Cc: Martin Pohlack
Todo:
* Should be moved to sysctl to only allow Dom0 access
* Maybe convert to binary transport to userland instead of printable form
* use ld to actually embed the build ID
* convert to textual representation in hypervisor and report in
printable form
Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
---
xen/arch/x86/Makefile | 4 ++--
xen/arch/x86/xen.lds.S | 5 +++++
xen/common/kernel.c | 33 +++++++++++++++++++++++++++++----
xen/common/version.c | 5 -----
xen/include/xen/compile.h.in | 1 -
5 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f24951..f724bd8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -108,11 +108,11 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..2176782 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -67,6 +67,11 @@ SECTIONS
*(.rodata.*)
} :text
+ .note.gnu.build-id : {
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ } :text
+
. = ALIGN(SMP_CACHE_BYTES);
.data.read_mostly : {
/* Exception table */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index e9d41b6..9814585 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -6,9 +6,11 @@
#include <xen/init.h>
#include <xen/lib.h>
+#include <xen/elf.h>
#include <xen/errno.h>
#include <xen/version.h>
#include <xen/sched.h>
+#include <xen/types.h>
#include <xen/paging.h>
#include <xen/nmi.h>
#include <xen/guest_access.h>
@@ -227,6 +229,10 @@ void __init do_initcalls(void)
* Simple hypercalls.
*/
+#define NT_GNU_BUILD_ID 3
+
+extern char * __note_gnu_build_id_start; /* defined in linker script */
+
DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
switch ( cmd )
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_build_id:
{
- xen_build_id_t build_id;
+ xen_build_id_t ascii_id;
+ Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
+ char * binary_id;
+ int i;
+
+ memset(ascii_id, 0, sizeof(ascii_id));
+
+ /* check if we really have a build-id */
+ if ( NT_GNU_BUILD_ID != n->type )
+ return 0;
+
+ /* sanity check, name should be "GNU" for ld-generated build-id */
+ if ( 0 != strncmp(ELFNOTE_NAME(n), "GNU", n->namesz))
+ return 0;
+
+ binary_id = (char *)ELFNOTE_DESC(n);
+
+ /* convert to printable format */
+ for (i = 0; i < n->descsz && (i + 1) * 2 < sizeof(xen_build_id_t); i++)
+ {
+ snprintf(&ascii_id[i * 2], 3, "%02hhx", binary_id[i]);
+ }
- memset(build_id, 0, sizeof(build_id));
- safe_strcpy(build_id, xen_build_id());
- if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
+ if ( copy_to_guest(arg, ascii_id, ARRAY_SIZE(ascii_id)) )
return -EFAULT;
return 0;
}
diff --git a/xen/common/version.c b/xen/common/version.c
index 5c3dbb0..b152e27 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -55,8 +55,3 @@ const char *xen_banner(void)
{
return XEN_BANNER;
}
-
-const char *xen_build_id(void)
-{
- return XEN_BUILD_ID;
-}
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 939685e..440ecb2 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -10,5 +10,4 @@
#define XEN_EXTRAVERSION "@@extraversion@@"
#define XEN_CHANGESET "@@changeset@@"
-#define XEN_BUILD_ID "@@changeset@@"
#define XEN_BANNER \
--
2.5.0
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply related [flat|nested] 170+ messages in thread* Re: [PATCH] xsplice: Use ld-embedded build-ids
2015-08-05 14:09 ` [PATCH] xsplice: Use ld-embedded build-ids Martin Pohlack
@ 2015-08-11 14:12 ` Jan Beulich
2015-08-14 12:59 ` Martin Pohlack
0 siblings, 1 reply; 170+ messages in thread
From: Jan Beulich @ 2015-08-11 14:12 UTC (permalink / raw)
To: Martin Pohlack, Martin Pohlack
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
dslutz, fanhenglong, Bjoern Doebel
>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
> Todo:
> * Should be moved to sysctl to only allow Dom0 access
Because of?
> * Maybe convert to binary transport to userland instead of printable form
Indeed.
> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>
> case XENVER_build_id:
> {
> - xen_build_id_t build_id;
> + xen_build_id_t ascii_id;
> + Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
> + char * binary_id;
> + int i;
> +
> + memset(ascii_id, 0, sizeof(ascii_id));
> +
> + /* check if we really have a build-id */
> + if ( NT_GNU_BUILD_ID != n->type )
> + return 0;
This needs to signal an error.
> +
> + /* sanity check, name should be "GNU" for ld-generated build-id */
> + if ( 0 != strncmp(ELFNOTE_NAME(n), "GNU", n->namesz))
> + return 0;
Same here.
> + binary_id = (char *)ELFNOTE_DESC(n);
> +
> + /* convert to printable format */
> + for (i = 0; i < n->descsz && (i + 1) * 2 < sizeof(xen_build_id_t); i++)
> + {
> + snprintf(&ascii_id[i * 2], 3, "%02hhx", binary_id[i]);
> + }
No need for the braces, and no need for the"hh" modifier.
Jan
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [PATCH] xsplice: Use ld-embedded build-ids
2015-08-11 14:12 ` Jan Beulich
@ 2015-08-14 12:59 ` Martin Pohlack
2015-08-14 13:54 ` Jan Beulich
0 siblings, 1 reply; 170+ messages in thread
From: Martin Pohlack @ 2015-08-14 12:59 UTC (permalink / raw)
To: Jan Beulich, Martin Pohlack
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
dslutz, fanhenglong, Bjoern Doebel
On 11.08.2015 16:12, Jan Beulich wrote:
>>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
>> Todo:
>> * Should be moved to sysctl to only allow Dom0 access
>
> Because of?
The discussion in this thread:
[Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
was:
----------------------------------------------------------------------
>> Martin Pohlack:
>> We should not expose the build_id to normal guests, but only to Dom0.
>>
>> A build_id uniquely identifies a specific build and I don't see how that
>> information would be required from DomU. It might actually help an
>> attacker to build his return-oriented programming exploit against a
>> specific build.
>>
>> The normal version numbers should be enough to know about capabilities
>> and API.
>
> Andrew Cooper:
>
> It will need its own XSM hook, but need not be strictly limited to just
> dom0.
----------------------------------------------------------------------
>> * Maybe convert to binary transport to userland instead of printable form
>
> Indeed.
>
>> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>
>> case XENVER_build_id:
>> {
>> - xen_build_id_t build_id;
>> + xen_build_id_t ascii_id;
>> + Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
>> + char * binary_id;
>> + int i;
>> +
>> + memset(ascii_id, 0, sizeof(ascii_id));
>> +
>> + /* check if we really have a build-id */
>> + if ( NT_GNU_BUILD_ID != n->type )
>> + return 0;
>
> This needs to signal an error.
Yes, ENOSYS, (or ENOENT, ENODATA)?
>> +
>> + /* sanity check, name should be "GNU" for ld-generated build-id */
>> + if ( 0 != strncmp(ELFNOTE_NAME(n), "GNU", n->namesz))
>> + return 0;
>
> Same here.
>
>> + binary_id = (char *)ELFNOTE_DESC(n);
>> +
>> + /* convert to printable format */
>> + for (i = 0; i < n->descsz && (i + 1) * 2 < sizeof(xen_build_id_t); i++)
>> + {
>> + snprintf(&ascii_id[i * 2], 3, "%02hhx", binary_id[i]);
>> + }
>
> No need for the braces, and no need for the"hh" modifier.
>
> Jan
>
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [PATCH] xsplice: Use ld-embedded build-ids
2015-08-14 12:59 ` Martin Pohlack
@ 2015-08-14 13:54 ` Jan Beulich
2015-08-14 13:57 ` Martin Pohlack
0 siblings, 1 reply; 170+ messages in thread
From: Jan Beulich @ 2015-08-14 13:54 UTC (permalink / raw)
To: Martin Pohlack, Martin Pohlack
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
dslutz, fanhenglong, Bjoern Doebel
>>> On 14.08.15 at 14:59, <mpohlack@amazon.com> wrote:
> On 11.08.2015 16:12, Jan Beulich wrote:
>>>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
>>> Todo:
>>> * Should be moved to sysctl to only allow Dom0 access
>>
>> Because of?
>
> The discussion in this thread:
>
> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>
> was:
> ----------------------------------------------------------------------
>>> Martin Pohlack:
>>> We should not expose the build_id to normal guests, but only to Dom0.
>>>
>>> A build_id uniquely identifies a specific build and I don't see how that
>>> information would be required from DomU. It might actually help an
>>> attacker to build his return-oriented programming exploit against a
>>> specific build.
>>>
>>> The normal version numbers should be enough to know about capabilities
>>> and API.
>>
>> Andrew Cooper:
>>
>> It will need its own XSM hook, but need not be strictly limited to just
>> dom0.
> ----------------------------------------------------------------------
So I'm confused - I asked "why Dom0 only" and then you point me to
Andrew saying it doesn't need to be Dom0 only?
>>> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
>>> case XENVER_build_id:
>>> {
>>> - xen_build_id_t build_id;
>>> + xen_build_id_t ascii_id;
>>> + Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
>>> + char * binary_id;
>>> + int i;
>>> +
>>> + memset(ascii_id, 0, sizeof(ascii_id));
>>> +
>>> + /* check if we really have a build-id */
>>> + if ( NT_GNU_BUILD_ID != n->type )
>>> + return 0;
>>
>> This needs to signal an error.
>
> Yes, ENOSYS, (or ENOENT, ENODATA)?
Definitely not ENOSYS. ENODATA or EOPNOTSUPP.
Jan
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [PATCH] xsplice: Use ld-embedded build-ids
2015-08-14 13:54 ` Jan Beulich
@ 2015-08-14 13:57 ` Martin Pohlack
2015-09-15 18:38 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 170+ messages in thread
From: Martin Pohlack @ 2015-08-14 13:57 UTC (permalink / raw)
To: Jan Beulich, Martin Pohlack
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
dslutz, fanhenglong, Bjoern Doebel
On 14.08.2015 15:54, Jan Beulich wrote:
>>>> On 14.08.15 at 14:59, <mpohlack@amazon.com> wrote:
>> On 11.08.2015 16:12, Jan Beulich wrote:
>>>>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
>>>> Todo:
>>>> * Should be moved to sysctl to only allow Dom0 access
>>>
>>> Because of?
>>
>> The discussion in this thread:
>>
>> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>>
>> was:
>> ----------------------------------------------------------------------
>>>> Martin Pohlack:
>>>> We should not expose the build_id to normal guests, but only to Dom0.
>>>>
>>>> A build_id uniquely identifies a specific build and I don't see how that
>>>> information would be required from DomU. It might actually help an
>>>> attacker to build his return-oriented programming exploit against a
>>>> specific build.
>>>>
>>>> The normal version numbers should be enough to know about capabilities
>>>> and API.
>>>
>>> Andrew Cooper:
>>>
>>> It will need its own XSM hook, but need not be strictly limited to just
>>> dom0.
>> ----------------------------------------------------------------------
>
> So I'm confused - I asked "why Dom0 only" and then you point me to
> Andrew saying it doesn't need to be Dom0 only?
Sorry about that, my (not expressed) thinking was that we should
restrict that to Dom0 for the XSM-disabled case.
>>>> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>
>>>> case XENVER_build_id:
>>>> {
>>>> - xen_build_id_t build_id;
>>>> + xen_build_id_t ascii_id;
>>>> + Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
>>>> + char * binary_id;
>>>> + int i;
>>>> +
>>>> + memset(ascii_id, 0, sizeof(ascii_id));
>>>> +
>>>> + /* check if we really have a build-id */
>>>> + if ( NT_GNU_BUILD_ID != n->type )
>>>> + return 0;
>>>
>>> This needs to signal an error.
>>
>> Yes, ENOSYS, (or ENOENT, ENODATA)?
>
> Definitely not ENOSYS. ENODATA or EOPNOTSUPP.
>
> Jan
>
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: [PATCH] xsplice: Use ld-embedded build-ids
2015-08-14 13:57 ` Martin Pohlack
@ 2015-09-15 18:38 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-09-15 18:38 UTC (permalink / raw)
To: Martin Pohlack
Cc: elena.ufimtseva, Jeremy Fitzhardinge, hanweidong, Martin Pohlack,
Jan Beulich, john.liuqiming, paul.voccio, Daniel Kiper,
major.hayden, liuyingdong, aliguori, xiantao.zxt, steven.wilson,
peter.huangpeng, Matt Wilson, xen-devel, rick.harris,
josh.kearney, jinsong.liu, amesserl, dslutz, fanhenglong,
Bjoern Doebel
On Fri, Aug 14, 2015 at 9:57 AM, Martin Pohlack <mpohlack@amazon.com> wrote:
> On 14.08.2015 15:54, Jan Beulich wrote:
>>>>> On 14.08.15 at 14:59, <mpohlack@amazon.com> wrote:
>>> On 11.08.2015 16:12, Jan Beulich wrote:
>>>>>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
>>>>> Todo:
>>>>> * Should be moved to sysctl to only allow Dom0 access
>>>>
>>>> Because of?
>>>
>>> The discussion in this thread:
>>>
>>> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>>>
>>> was:
>>> ----------------------------------------------------------------------
>>>>> Martin Pohlack:
>>>>> We should not expose the build_id to normal guests, but only to Dom0.
>>>>>
>>>>> A build_id uniquely identifies a specific build and I don't see how that
>>>>> information would be required from DomU. It might actually help an
>>>>> attacker to build his return-oriented programming exploit against a
>>>>> specific build.
>>>>>
>>>>> The normal version numbers should be enough to know about capabilities
>>>>> and API.
>>>>
>>>> Andrew Cooper:
>>>>
>>>> It will need its own XSM hook, but need not be strictly limited to just
>>>> dom0.
>>> ----------------------------------------------------------------------
>>
>> So I'm confused - I asked "why Dom0 only" and then you point me to
>> Andrew saying it doesn't need to be Dom0 only?
>
> Sorry about that, my (not expressed) thinking was that we should
> restrict that to Dom0 for the XSM-disabled case.
>
That may make this more complex.
If we want to restrict it to this we may as well just stick this in sysctl
and have it be part of the xsplice ops.
Let me do that.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
2015-07-28 15:51 ` Andrew Cooper
2015-08-05 8:50 ` Martin Pohlack
@ 2015-08-11 14:02 ` Jan Beulich
2 siblings, 0 replies; 170+ messages in thread
From: Jan Beulich @ 2015-08-11 14:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
daniel.kiper, major.hayden, liuyingdong, aliguori, xiantao.zxt,
steven.wilson, peter.huangpeng, msw, xen-devel, rick.harris,
josh.kearney, jinsong.liu, amesserl, mpohlack, dslutz,
fanhenglong, Andrew.Cooper3
>>> On 27.07.15 at 21:20, <konrad@kernel.org> wrote:
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -10,4 +10,5 @@
> #define XEN_EXTRAVERSION "@@extraversion@@"
>
> #define XEN_CHANGESET "@@changeset@@"
> +#define XEN_BUILD_ID "@@changeset@@"
How can the changset be a valid / sufficient build ID (even if maybe
this is intended to only be a default / fallback)? Wasn't this meant
to specifically account for rebuilds (with, say, a compiler slightly
updated from the original one, and hence possibly producing
slightly different code)?
Jan
^ permalink raw reply [flat|nested] 170+ messages in thread
* Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.)
2015-07-27 19:20 [RFC PATCH v3.1] xSplice design Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
@ 2015-08-05 8:55 ` Martin Pohlack
2015-08-05 13:25 ` Hotpatch construction and __LINE__ Andrew Cooper
2015-11-03 18:21 ` Ross Lagerwall
2 siblings, 2 replies; 170+ messages in thread
From: Martin Pohlack @ 2015-08-05 8:55 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel, msw, aliguori, amesserl,
rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich,
Andrew.Cooper3, jeremy, dslutz, Doebel, Bjoern
Hi,
Another high-level point to think about is how we want to handle inlined
__LINE__ references. This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
infrastructure in Xen.
Let me try to explain the problem:
We have file1.c with functions f1 and f2 (in that order). f2 contains a
BUG() (or WARN()) macro and at that point embeds the source line number
into the generated code for f2.
Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
lines to f1 and as a consequence shifts out f2 by two lines. The newly
constructed file1.o will now contain differences in both binary
functions f1 (because we actually changed it with the applied patch) and
f2 (because the contained BUG macro embeds the new line number).
Without additional information, an algorithm comparing file1.o before
and after hotpatch application will determine both functions to be
changed and will have to include both into the binary hotpatch.
Options:
1. Transform source code patches for hotpatches to be line-neutral for
each chunk. This can be done in almost all cases with either
reformatting of the source code or by introducing artificial
preprocessor "#line n" directives to adjust for the introduced
differences.
This approach is low-tech and simple. Potentially generated
backtraces and existing debug information refers to the original
build and does not reflect hotpatching state except for actually
hotpatched functions but should be mostly correct.
2. Ignoring the problem and living with artificially large hotpatches
that unnecessarily patch many functions.
This approach might lead to some very large hotpatches depending on
content of specific source file. It may also trigger pulling in
functions into the hotpatch that cannot reasonable be hotpatched due
to limitations of a hotpatching framework (init-sections, parts of
the hotpatching framework itself, ...) and may thereby prevent us
from patching a specific problem.
The decision between 1. and 2. can be made on a patch--by-patch
basis.
3. Introducing an indirection table for storing line numbers and
treating that specially for binary diffing. I believe Linux follows
this approach, but the details escape me ATM.
We might either use this indirection table for runtime use and patch
that with each hotpatch (similarly to exception tables) or we might
purely use it when building hotpatches to ignore functions that only
differ at exactly the location where a line-number is embedded.
Similar considerations are true to a lesser extent for __FILE__, but I
would argue that file renaming should be done outside of hotpatches.
Martin
On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> Since v3 [http://lists.xen.org/archives/html/xen-devel/2015-07/msg00990.html]
> - Nailed down the comments, ingested them in.
> - Wrote and tested some code.
> RFC v2 [http://lists.xen.org/archives/html/xen-devel/2015-05/msg02142.html]
> - Ingested every review comment in.
>
>
> The patches for the code are a shell - there is no patching done at all and
> it is very much just to test out the design and hypercalls. The hard parts
> are yet to come :-)
>
> At the Seattle LinuxCon/Xen Summit I will be presenting about xSplice and
> referring to this URL. There is also an slot for brainstorming to talk
> in details about things we disagree - and there is ample time to talk
> during dinner. Martin who has been heavily reviewing the design will be there
> and I hope other folks will be there as well to shape the design and
> how we want this to work.
>
> The big outstanding issues are how we want to handle preemption. That
> is the problem of making an hypercall and waiting for the hypervisor
> to do its job (and the VCPU is blocked). In the past some XSAs have come
> out to resolve this and I would very much like this to have it addressed at start.
>
> I think the other issues that have been raised should also be discussed
> naturally, but the above is crucial (at least for me). I've attached the
> patches on how I thought the preemption part could be solved by having an 'worker'
> in hypervisor acting on the commands - and we just poll on the status to see
> what the hypervisor has done so far.
>
> Lastly, I also plan to add an Wiki to outline the dependency implementation
> parts that so far bubbled up - I figured Wiki would be better as some folks
> could put their name behind it.
>
> Now please excuse the roughness of the patch and this giant one huge having
> everything in it. It ought to be split in three at least: hypervisor, toolstacks
> (libxc and libxl) - that is to be done later.
>
> docs/misc/xsplice.h | 80 +++
> docs/misc/xsplice.markdown | 1230 +++++++++++++++++++++++++++++++++++++++++
> docs/misc/xsplice_test.c | 78 +++
> tools/libxc/include/xenctrl.h | 16 +
> tools/libxc/xc_misc.c | 183 ++++++
> tools/libxc/xc_private.c | 3 +
> tools/misc/Makefile | 4 +
> tools/misc/xen-xsplice.c | 385 +++++++++++++
> xen/common/Makefile | 1 +
> xen/common/kernel.c | 11 +
> xen/common/keyhandler.c | 8 +-
> xen/common/sysctl.c | 5 +
> xen/common/version.c | 5 +
> xen/common/xsplice.c | 405 ++++++++++++++
> xen/include/public/sysctl.h | 66 +++
> xen/include/public/version.h | 4 +
> xen/include/xen/compile.h.in | 1 +
> xen/include/xen/version.h | 1 +
> xen/include/xen/xsplice.h | 9 +
> 19 files changed, 2494 insertions(+), 1 deletion(-)
>
> Konrad Rzeszutek Wilk (2):
> xsplice: rfc.v3.1
> xsplice: Add hook for build_id
>
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: Hotpatch construction and __LINE__
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
@ 2015-08-05 13:25 ` Andrew Cooper
2015-08-12 8:09 ` Jan Beulich
2015-11-03 18:21 ` Ross Lagerwall
1 sibling, 1 reply; 170+ messages in thread
From: Andrew Cooper @ 2015-08-05 13:25 UTC (permalink / raw)
To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
dslutz, Doebel, Bjoern
On 05/08/15 09:55, Martin Pohlack wrote:
> Hi,
>
> Another high-level point to think about is how we want to handle inlined
> __LINE__ references. This problem is related to hotpatch construction
> and potentially has influence on the design of the hotpatching
> infrastructure in Xen.
>
> Let me try to explain the problem:
>
> We have file1.c with functions f1 and f2 (in that order). f2 contains a
> BUG() (or WARN()) macro and at that point embeds the source line number
> into the generated code for f2.
>
> Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
> lines to f1 and as a consequence shifts out f2 by two lines. The newly
> constructed file1.o will now contain differences in both binary
> functions f1 (because we actually changed it with the applied patch) and
> f2 (because the contained BUG macro embeds the new line number).
>
> Without additional information, an algorithm comparing file1.o before
> and after hotpatch application will determine both functions to be
> changed and will have to include both into the binary hotpatch.
>
> Options:
>
> 1. Transform source code patches for hotpatches to be line-neutral for
> each chunk. This can be done in almost all cases with either
> reformatting of the source code or by introducing artificial
> preprocessor "#line n" directives to adjust for the introduced
> differences.
>
> This approach is low-tech and simple. Potentially generated
> backtraces and existing debug information refers to the original
> build and does not reflect hotpatching state except for actually
> hotpatched functions but should be mostly correct.
>
> 2. Ignoring the problem and living with artificially large hotpatches
> that unnecessarily patch many functions.
>
> This approach might lead to some very large hotpatches depending on
> content of specific source file. It may also trigger pulling in
> functions into the hotpatch that cannot reasonable be hotpatched due
> to limitations of a hotpatching framework (init-sections, parts of
> the hotpatching framework itself, ...) and may thereby prevent us
> from patching a specific problem.
>
> The decision between 1. and 2. can be made on a patch--by-patch
> basis.
>
> 3. Introducing an indirection table for storing line numbers and
> treating that specially for binary diffing. I believe Linux follows
> this approach, but the details escape me ATM.
>
> We might either use this indirection table for runtime use and patch
> that with each hotpatch (similarly to exception tables) or we might
> purely use it when building hotpatches to ignore functions that only
> differ at exactly the location where a line-number is embedded.
>
> Similar considerations are true to a lesser extent for __FILE__, but I
> would argue that file renaming should be done outside of hotpatches.
Looking at `strings xen-syms`, we have very few embedded
__FILE__/__LINE__'s in other strings, meaning that most come from %s/%d
formatting.
bug/warn/assert frames have their references in the exception table, so
should be reasonably self contained to fix up.
Regular printk()s are definitely more problematic however. Their
references will typically be in %rsi/%rdx and shifting any #line
reference across the 256 boundary will change the encoding size of
setting the print up.
Jan had a plan to make Xen read its own DWARF symbol table rather than
using the current cludge we have where we partially link Xen, extract
the public symbol table, rewrite symbol-offsets.c and relink it onto the
end.
Perhaps there is an opportunity to piggy-back onto that and have all
file/line references coming from the DWARF information. I suspect this
will be similar to what Linux does, as it already has support for using
its own DWARF/STABS information.
Personally, I think #2 should be avoided wherever possible. The bigger
the hotpatch, the greater the opportunity for something to go wrong.
Any panic/stack trace should be able to identify exactly which Xen is
running, including some hotpatch status. Hopatches will be[1] small
targeted fixes, so I don't think it is unreasonable to expect someone
interpreting a stack trace to need to adjust file/line references by the
hotpatch delta.
~Andrew
[1] woe betide anyone attempting to use hotpatches for general software
updates.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: Hotpatch construction and __LINE__
2015-08-05 13:25 ` Hotpatch construction and __LINE__ Andrew Cooper
@ 2015-08-12 8:09 ` Jan Beulich
2015-08-12 9:55 ` Andrew Cooper
0 siblings, 1 reply; 170+ messages in thread
From: Jan Beulich @ 2015-08-12 8:09 UTC (permalink / raw)
To: Andrew Cooper
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
Martin Pohlack, dslutz, fanhenglong, Bjoern Doebel
>>> On 05.08.15 at 15:25, <andrew.cooper3@citrix.com> wrote:
> Jan had a plan to make Xen read its own DWARF symbol table rather than
> using the current cludge we have where we partially link Xen, extract
> the public symbol table, rewrite symbol-offsets.c and relink it onto the
> end.
Either I mis-expressed this, or you mis-remember: I'm in no way
intending to use DWARF information. What I want to use is the
_full_ ELF / COFF symbol table instead of nm output (which has
quite a bit of interesting information discarded).
> Perhaps there is an opportunity to piggy-back onto that and have all
> file/line references coming from the DWARF information. I suspect this
> will be similar to what Linux does, as it already has support for using
> its own DWARF/STABS information.
I'm curious where you found this as I'm unaware of such
functionality. Recently they even decided to discard all
.eh_frame / .dwarf_frame generating annotations the
compiler can't itself generate.
Jan
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: Hotpatch construction and __LINE__
2015-08-12 8:09 ` Jan Beulich
@ 2015-08-12 9:55 ` Andrew Cooper
0 siblings, 0 replies; 170+ messages in thread
From: Andrew Cooper @ 2015-08-12 9:55 UTC (permalink / raw)
To: Jan Beulich
Cc: elena.ufimtseva, jeremy, hanweidong, john.liuqiming, paul.voccio,
Konrad Rzeszutek Wilk, daniel.kiper, major.hayden, liuyingdong,
aliguori, xiantao.zxt, steven.wilson, peter.huangpeng, msw,
xen-devel, rick.harris, josh.kearney, jinsong.liu, amesserl,
Martin Pohlack, dslutz, fanhenglong, Bjoern Doebel
On 12/08/15 09:09, Jan Beulich wrote:
>>>> On 05.08.15 at 15:25, <andrew.cooper3@citrix.com> wrote:
>> Jan had a plan to make Xen read its own DWARF symbol table rather than
>> using the current cludge we have where we partially link Xen, extract
>> the public symbol table, rewrite symbol-offsets.c and relink it onto the
>> end.
> Either I mis-expressed this, or you mis-remember: I'm in no way
> intending to use DWARF information. What I want to use is the
> _full_ ELF / COFF symbol table instead of nm output (which has
> quite a bit of interesting information discarded).
I misremembered. Sorry.
>
>> Perhaps there is an opportunity to piggy-back onto that and have all
>> file/line references coming from the DWARF information. I suspect this
>> will be similar to what Linux does, as it already has support for using
>> its own DWARF/STABS information.
> I'm curious where you found this as I'm unaware of such
> functionality.
The x86 linker script includes the information (given appropriate
CONFIG_ options), and the perf subsystem appears to have code to
interpret itself.
~Andrew
> Recently they even decided to discard all
> .eh_frame / .dwarf_frame generating annotations the
> compiler can't itself generate.
>
> Jan
>
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: Hotpatch construction and __LINE__
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
2015-08-05 13:25 ` Hotpatch construction and __LINE__ Andrew Cooper
@ 2015-11-03 18:21 ` Ross Lagerwall
1 sibling, 0 replies; 170+ messages in thread
From: Ross Lagerwall @ 2015-11-03 18:21 UTC (permalink / raw)
To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
fanhenglong, liuyingdong, john.liuqiming, jbeulich,
Andrew.Cooper3, jeremy, dslutz, Doebel, Bjoern
On 08/05/2015 09:55 AM, Martin Pohlack wrote:
> Hi,
>
> Another high-level point to think about is how we want to handle inlined
> __LINE__ references. This problem is related to hotpatch construction
> and potentially has influence on the design of the hotpatching
> infrastructure in Xen.
>
> Let me try to explain the problem:
>
> We have file1.c with functions f1 and f2 (in that order). f2 contains a
> BUG() (or WARN()) macro and at that point embeds the source line number
> into the generated code for f2.
>
> Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
> lines to f1 and as a consequence shifts out f2 by two lines. The newly
> constructed file1.o will now contain differences in both binary
> functions f1 (because we actually changed it with the applied patch) and
> f2 (because the contained BUG macro embeds the new line number).
>
> Without additional information, an algorithm comparing file1.o before
> and after hotpatch application will determine both functions to be
> changed and will have to include both into the binary hotpatch.
>
> Options:
>
> 1. Transform source code patches for hotpatches to be line-neutral for
> each chunk. This can be done in almost all cases with either
> reformatting of the source code or by introducing artificial
> preprocessor "#line n" directives to adjust for the introduced
> differences.
>
> This approach is low-tech and simple. Potentially generated
> backtraces and existing debug information refers to the original
> build and does not reflect hotpatching state except for actually
> hotpatched functions but should be mostly correct.
>
> 2. Ignoring the problem and living with artificially large hotpatches
> that unnecessarily patch many functions.
>
> This approach might lead to some very large hotpatches depending on
> content of specific source file. It may also trigger pulling in
> functions into the hotpatch that cannot reasonable be hotpatched due
> to limitations of a hotpatching framework (init-sections, parts of
> the hotpatching framework itself, ...) and may thereby prevent us
> from patching a specific problem.
>
> The decision between 1. and 2. can be made on a patch--by-patch
> basis.
>
> 3. Introducing an indirection table for storing line numbers and
> treating that specially for binary diffing. I believe Linux follows
> this approach, but the details escape me ATM.
>
> We might either use this indirection table for runtime use and patch
> that with each hotpatch (similarly to exception tables) or we might
> purely use it when building hotpatches to ignore functions that only
> differ at exactly the location where a line-number is embedded.
>
For BUG, ASSERT, and WARN, the line number is stored in the bug frame
table and as currently implemented, the build tool ignores changes to
the bug frame table if there's no corresponding functional change. Which
mostly fixes this issue.
--
Ross Lagerwall
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2018-11-19 17:26 Razvan Cojocaru
2018-11-19 17:34 ` Razvan Cojocaru
0 siblings, 1 reply; 170+ messages in thread
From: Razvan Cojocaru @ 2018-11-19 17:26 UTC (permalink / raw)
To: xen-devel
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).
The first patch introduces p2m_{init,free}_logdirty(), the second
allocates a new logdirty rangeset for each new altp2m, and the
fourth propagates (under lock) changes to all p2ms.
Since the last version of the series, what has previously been
the first patch is already upstream, and two patches kindly
authored by George Dunlap have been appended. The patches
optimize the way rangeset changes are propagated in
change_type_range().
[PATCH V7 1/5] x86/mm: introduce p2m_{init,free}_logdirty()
[PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms
[PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early
[PATCH V7 4/5] p2m: Always use hostp2m when clipping rangesets
[PATCH V7 5/5] p2m: change_range_type: Only invalidate mapped gfns
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2017-11-15 15:29 futurelieswithin
0 siblings, 0 replies; 170+ messages in thread
From: futurelieswithin @ 2017-11-15 15:29 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 299 bytes --]
A story perhaps i remember snapping my fingers and at mr miagi request it actually makes things appear and quantasize then a paculiar planet red and orange appeared outa nowhere it was a Pic of what the earth looked like 13.6 billion years
Sent from my Samsung Galaxy , an AT&T LTE smartphone
[-- Attachment #1.2: Type: text/html, Size: 577 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2017-08-25 5:16 Chao Gao
0 siblings, 0 replies; 170+ messages in thread
From: Chao Gao @ 2017-08-25 5:16 UTC (permalink / raw)
To: xen-devel
Cc: Kevin Tian, Stefano Stabellini, Wei Liu, George Dunlap,
Ian Jackson, Tim Deegan, Jan Beulich, Andrew Cooper, Chao Gao,
Crawford Eric R, Roger Pau Monné
From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao <chao.gao@intel.com>
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
the same VT-d unit as the 'Traditional Functions' on the endpoint. To search
VT-d unit, the BDF of PF or the BDF of a traditional function may be used. And
it depends on whether the PF is an extended function or not.
Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'. But it
is conceptually wrong w/o checking whether PF is an extended function and
would lead to match VFs of a RC endpoint to a wrong VT-d unit.
This patch uses VF's 'is_extfn' field to indicate whether the PF of this VF is
an extended function. The field helps to use correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
v9:
- check 'is_virtfn' first in pci_add_device() to avoid potential error if
linux side sets VF's 'is_extfn'
- comments changes to make it clear that we use VF's 'is_extfn' intentionally
otherwise the patch seems like a workaround.
v8:
- use "conceptually wrong", instead of "a corner case" in commit message
- check 'is_virtfn' first in acpi_find_matched_drhd_unit()
v7:
- Drop Eric's tested-by
- Change commit message to be clearer
- Re-use VF's is_extfn field
- access PF's is_extfn field in locked area
---
xen/drivers/passthrough/pci.c | 14 ++++++++++----
xen/drivers/passthrough/vtd/dmar.c | 12 ++++++------
xen/include/xen/pci.h | 1 +
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..0e27e29 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,21 +599,24 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
const char *pdev_type;
int ret;
+ bool pf_is_extfn = false;
- if (!info)
+ if ( !info )
pdev_type = "device";
- else if (info->is_extfn)
- pdev_type = "extended function";
- else if (info->is_virtfn)
+ else if ( info->is_virtfn )
{
pcidevs_lock();
pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
+ if ( pdev )
+ pf_is_extfn = pdev->info.is_extfn;
pcidevs_unlock();
if ( !pdev )
pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
NULL, node);
pdev_type = "virtual function";
}
+ else if ( info->is_extfn )
+ pdev_type = "extended function";
else
{
info = NULL;
@@ -707,6 +710,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, ctrl);
}
+ /* VF's 'is_extfn' is used to indicate whether PF is an extended function */
+ if ( pdev->info.is_virtfn )
+ pdev->info.is_extfn = pf_is_extfn;
check_pdev(pdev);
ret = 0;
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..75c9c92 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -211,15 +211,15 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *pdev)
if ( pdev == NULL )
return NULL;
- if ( pdev->info.is_extfn )
+ if ( pdev->info.is_virtfn )
{
- bus = pdev->bus;
- devfn = 0;
+ bus = pdev->info.physfn.bus;
+ devfn = pdev->info.is_extfn ? 0 : pdev->info.physfn.devfn;
}
- else if ( pdev->info.is_virtfn )
+ else if ( pdev->info.is_extfn )
{
- bus = pdev->info.physfn.bus;
- devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : pdev->info.physfn.devfn;
+ bus = pdev->bus;
+ devfn = 0;
}
else
{
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..4dd42ac 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -39,6 +39,7 @@
#define PCI_SBDF3(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b, df))
struct pci_dev_info {
+ /* VF's 'is_extfn' is used to show whether its PF an extended function */
bool_t is_extfn;
bool_t is_virtfn;
struct {
--
1.8.3.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 170+ messages in thread* (no subject)
@ 2017-07-28 5:27 Manonmani
0 siblings, 0 replies; 170+ messages in thread
From: Manonmani @ 2017-07-28 5:27 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]
Is it possible to use VFB for paravirtualised Guest? How to display
Domain-U in physical monitor? I have added vfb in my Guest configuration
and it returns the following error :
Parsing config from
/etc/xen/arch_domU_1.cfg
libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model
/usr/lib/xen/b
in/qemu-dm is not executable: No such file or
directory
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: (null): spawn
failed (
rc=-3)
libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model
did n
ot start: -3
Thanks in advance.
Regards,
Joker
[-- Attachment #1.2: Type: text/html, Size: 916 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2017-07-26 19:04 Raviprasad Gurikar
0 siblings, 0 replies; 170+ messages in thread
From: Raviprasad Gurikar @ 2017-07-26 19:04 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]
Hi .
I am ravi student from Indian I working on the xen arm development . I have plan to run the xen arm on fastmodel. But I am getting problem in the rootfilesystem creation and debootstrap for this link https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/RootFilesystem. I am not able to entry the chroot ; if give the commands like this
Sudo chroot /mnt;
Getting error like – error ; no such file or directory /bin/bash.
Please help me .
Sent from Mail for Windows 10
[-- Attachment #1.2: Type: text/html, Size: 2158 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2017-04-04 11:29 Seraphime Kirkovski
0 siblings, 0 replies; 170+ messages in thread
From: Seraphime Kirkovski @ 2017-04-04 11:29 UTC (permalink / raw)
Cc: Wei Liu, IanJackson, xen-devel
<ian.jackson@eu.citrix.com>
Bcc:
Subject: Re: [PATCH] libxc: fix segfault on uninitialized xch->fmem
Reply-To:
In-Reply-To: <20170404101507.lohlu5rbx4jq5md2@citrix.com>
On Tue, Apr 04, 2017 at 11:15:07AM +0100, Wei Liu wrote:
> Since there are a few handles in xch, it would be better to initialise
> them all at once by doing:
>
> struct xc_interface_core xch_buf = { 0 }
>
> > xch->flags = open_flags;
> > xch->dombuild_logger_file = 0;
> > xc_clear_last_error(xch);
> > --
> > 2.11.0
> >
Hi, thanks for the reply.
Literally 10 minutes after sending this, I thought that a bzero would
be better. Will send a V2 shortly.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2017-02-27 18:12 Dmitry Rockosov
2017-03-06 10:48 ` George Dunlap
0 siblings, 1 reply; 170+ messages in thread
From: Dmitry Rockosov @ 2017-02-27 18:12 UTC (permalink / raw)
To: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]
Hi guys,
Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?
Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.
Does it mean, we will get Virtual Interrupt on the next VM-entry?
Thank you!
Best Regards,
Rockosov Dmitry
[-- Attachment #1.2: Type: text/html, Size: 676 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2017-02-27 18:12 Dmitry Rockosov
@ 2017-03-06 10:48 ` George Dunlap
0 siblings, 0 replies; 170+ messages in thread
From: George Dunlap @ 2017-03-06 10:48 UTC (permalink / raw)
To: Dmitry Rockosov; +Cc: Tian, Kevin, Xen-devel
On Mon, Feb 27, 2017 at 6:12 PM, Dmitry Rockosov <rockosov@gmail.com> wrote:
> Hi guys,
>
> Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery is
> blocking by STI?
>
> Previously, VMM used Interrupt-Window, but as I see in XEN code,
> Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.
>
> Does it mean, we will get Virtual Interrupt on the next VM-entry?
CC'ing the VMX maintainer.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2017-02-17 17:17 dhara buch
2017-02-20 17:56 ` Dario Faggioli
0 siblings, 1 reply; 170+ messages in thread
From: dhara buch @ 2017-02-17 17:17 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]
Hello,
I have installed Ubuntu 15.10 in which have installed Xen with source.
Booting is done with Xen as well as commands like xl infor, xl list are
also working fine.
For creating Virtual Machine, I have installed Virtual Machine Manager, but
when I try to run it, it gives error as follows:
*Unable to connect to libvirt.internal error: libxenlight state driver is
not activeVerify that: - A Xen host kernel was booted - The Xen service has
been started*
I tried by installing libvirt as
apt-get install libvirt-bin
but, still the same problem is found. Libvirtd service is also not getting
started.
Where am I lacking?
Thank you,
Dhara Buch
[-- Attachment #1.2: Type: text/html, Size: 823 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2017-02-17 17:17 dhara buch
@ 2017-02-20 17:56 ` Dario Faggioli
0 siblings, 0 replies; 170+ messages in thread
From: Dario Faggioli @ 2017-02-20 17:56 UTC (permalink / raw)
To: dhara buch, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]
On Fri, 2017-02-17 at 22:47 +0530, dhara buch wrote:
> Hello,
>
> I have installed Ubuntu 15.10 in which have installed Xen with
> source.
>
> Booting is done with Xen as well as commands like xl infor, xl list
> are also working fine.
>
> For creating Virtual Machine, I have installed Virtual Machine
> Manager, but when I try to run it, it gives error as follows:
>
> Unable to connect to libvirt.
>
> internal error: libxenlight state driver is not active
>
This means you have not installed the libvirt, libxl driver. Or that
you have, but trying to load it is failing.
There should be something in the libvirt logs.
However, since you said you've installed Xen from sources, you probably
need to build and install libvirt from sources too.
In fact, I don't know how exactly it is in Ubuntu, but in all the
distro I've tried, trying to install libvirt-daemon-driver-libxl (or
whatever the package is called), would fail, unless Xen hypervisor,
toolstack and libraries are also installed with the distro package
mamanger.
If that is not the case, install would either fail, or would bring in
those Xen packages, which would then either overrun or conflict with
your source installation.
> Verify that:
> - A Xen host kernel was booted
> - The Xen service has been started
>
> I tried by installing libvirt as
> apt-get install libvirt-bin
>
> but, still the same problem is found. Libvirtd service is also not
> getting started.
>
> Where am I lacking?
>
As said above. In all the distro I tried, when I build Xen from source,
I've always also had to build libvirt from sources.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2017-02-17 10:47 Norbert Manthey
2017-02-17 11:35 ` Andrew Cooper
0 siblings, 1 reply; 170+ messages in thread
From: Norbert Manthey @ 2017-02-17 10:47 UTC (permalink / raw)
To: xen-devel
Dear Xen developers,
I would like to bring the attached two patches online, as they fix minor defects
in the upstream code base.
Best,
Norbert
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
[parent not found: <1484304406-10820-2-git-send-email-nicolas.dichtel@6wind.com>]
* (no subject)
@ 2016-12-29 0:56 Ronald Rojas
2017-01-04 1:10 ` Stefano Stabellini
0 siblings, 1 reply; 170+ messages in thread
From: Ronald Rojas @ 2016-12-29 0:56 UTC (permalink / raw)
Cc: Wei Liu, George Dunlap, Ian Jackson, George Dunlap, xen-devel
The first 57 commits are merged from previous work done by
George Dunlap at (https://github.com/gwd/schedbench) and
implement manipulating Cpu pool. The last 2 commits merge
his work onto the Xen tree and implement finding system
information and throwing errors.
CC: xen-devel <xen-devel@lists.xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: George Dunlap <dunlapg@umich.edu>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-11-28 17:18 Ronald Rojas
0 siblings, 0 replies; 170+ messages in thread
From: Ronald Rojas @ 2016-11-28 17:18 UTC (permalink / raw)
To: xen-devel, ian.jackson, wei.liu2, george.dunlap, dunlapg
Create a Makefile for the golang xenlight project, which will
allow users to access libxl functionality in Golang. Makefile
rules were also added to tools/Makefile for the project to be
built and installed. A template Golang file was also created
for the project to be properly built.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-07-16 11:51 姚 å¿ å°†
0 siblings, 0 replies; 170+ messages in thread
From: 姚 å¿ å°† @ 2016-07-16 11:51 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 785 bytes --]
Recently , I made a test to compare the performance of I/O between xen project and xenserver. I found the performance of xenserver is much better than that of xen project .
I want to find the reason why xenserver is better so I search through google.com. On the website www.xenproject.org<http://www.xenproject.org> , I found url http://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance and http://wiki.xenproject.org/wiki/Network_Throughput_and_Performance_Guide .
I set these parameters as the url given. But , it looks doesn’t work. The performance got no obvious improvement.
So , I send this mail to get some advise . will you help me ? if so , I’ll be much appreciate.
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
[-- Attachment #1.2: Type: text/html, Size: 3309 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-07-07 9:36 George Dunlap
2016-07-07 11:03 ` Dario Faggioli
0 siblings, 1 reply; 170+ messages in thread
From: George Dunlap @ 2016-07-07 9:36 UTC (permalink / raw)
To: Dario Faggioli; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson
On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percentage.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
The change looks good in itself; but it makes me realize that
technically by changing the trace format, the previous patch
introduced a regression which is fixed here. There's a part of me
that's tempted to overlook it because it's minor, but on balance I
think we should try to be diligent with this sort of thing.
Could you re-send this with the trace change moved from the previous
patch to this patch?
If you don't make any other changes, you can retain the reviewed-by of
the previous patch, and add this one to this patch:
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2016-07-07 9:36 George Dunlap
@ 2016-07-07 11:03 ` Dario Faggioli
2016-07-07 12:48 ` George Dunlap
0 siblings, 1 reply; 170+ messages in thread
From: Dario Faggioli @ 2016-07-07 11:03 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson
[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]
On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> >
> > in both xenalyze and formats (for xentrace_format).
> >
> > In particular, in xenalyze, now that we have the precision
> > of the fixed point load values in the tracepoint, show both
> > the raw value and the (easier to interpreet) percentage.
> >
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> The change looks good in itself; but it makes me realize that
> technically by changing the trace format, the previous patch
> introduced a regression which is fixed here. There's a part of me
> that's tempted to overlook it because it's minor, but on balance I
> think we should try to be diligent with this sort of thing.
>
Sure!
> Could you re-send this with the trace change moved from the previous
> patch to this patch?
>
So, you're saying I should change both Xen, xentrace_format and
xenalyze.c all at once, in the same patch, right?
I'm asking just to double check, as, although I see your point,
separating things by component seemed a good thing to do to me, even at
the price you describe, and I've done it before. :-)
As said, I'm fine doing that, I just want to be sure this is what you
are asking.
> If you don't make any other changes, you can retain the reviewed-by
> of
> the previous patch, and add this one to this patch:
>
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>
Ok, thanks.
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2016-07-07 11:03 ` Dario Faggioli
@ 2016-07-07 12:48 ` George Dunlap
2016-07-07 15:42 ` Dario Faggioli
2016-10-31 10:33 ` Ian Jackson
0 siblings, 2 replies; 170+ messages in thread
From: George Dunlap @ 2016-07-07 12:48 UTC (permalink / raw)
To: Dario Faggioli; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson
On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the fixed point load values in the tracepoint, show both
>>> the raw value and the (easier to interpreet) percentage.
>>>
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> The change looks good in itself; but it makes me realize that
>> technically by changing the trace format, the previous patch
>> introduced a regression which is fixed here. There's a part of me
>> that's tempted to overlook it because it's minor, but on balance I
>> think we should try to be diligent with this sort of thing.
>>
> Sure!
>
>> Could you re-send this with the trace change moved from the previous
>> patch to this patch?
>>
> So, you're saying I should change both Xen, xentrace_format and
> xenalyze.c all at once, in the same patch, right?
>
> I'm asking just to double check, as, although I see your point,
> separating things by component seemed a good thing to do to me, even at
> the price you describe, and I've done it before. :-)
>
> As said, I'm fine doing that, I just want to be sure this is what you
> are asking.
I think it often does make sense to check things out by component. And
of course before xenalyze was in tree, it doesn't matter when the change
was done. I suppose I've always been prejudiced against
xentrace_format, which is why I'd never thought about regressions in it
(although I probably should have).
But now that xenalyze is in-tree, I think we want to avoid situations
where the in-tree xenalyze is broken, even just for one changeset, if we
can avoid it.
Thanks,
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2016-07-07 12:48 ` George Dunlap
@ 2016-07-07 15:42 ` Dario Faggioli
2016-10-31 10:33 ` Ian Jackson
1 sibling, 0 replies; 170+ messages in thread
From: Dario Faggioli @ 2016-07-07 15:42 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson
[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]
On Thu, 2016-07-07 at 13:48 +0100, George Dunlap wrote:
> On 07/07/16 12:03, Dario Faggioli wrote:
> > On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> > > Could you re-send this with the trace change moved from the
> > > previous
> > > patch to this patch?
> > >
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
> >
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if
> we
> can avoid it.
>
Ok, this makes sense. Will do.
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2016-07-07 12:48 ` George Dunlap
2016-07-07 15:42 ` Dario Faggioli
@ 2016-10-31 10:33 ` Ian Jackson
1 sibling, 0 replies; 170+ messages in thread
From: Ian Jackson @ 2016-10-31 10:33 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Dario Faggioli, Wei Liu, Anshul Makkar
George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component. And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done. I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
>
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.
This kind of situation is not that uncommon. For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.
(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-05-19 14:34 Roger Pau Monné
0 siblings, 0 replies; 170+ messages in thread
From: Roger Pau Monné @ 2016-05-19 14:34 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Jan Beulich
<George.Dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan
Beulich <jbeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Stefano Stabellini <sstabellini@kernel.org>, Tim Deegan <tim@xen.org>, Wei
Liu <wei.liu2@citrix.com>
Bcc:
Subject: Bump library names just after branching
Reply-To:
Hello,
Currently we bump the shared library names just before the release, so ATM
xen-unstable is still using the library names from the 4.6 release. This is
an issue if someone wants to install both Xen 4.6 and xen-unstable in the
same box (unless you use a different prefix/DESTDIR), because libraries from
xen-unstable will replace the stable ones.
IMHO, it would make more sense to bump the library names just *after* we
branch and open the tree for development again. We could even have the
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so
that we don't need to go around the different library makefiles bumping the
versions manually.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-03-17 12:20 Safa Hamza
2016-03-18 11:34 ` Safa Hamza
0 siblings, 1 reply; 170+ messages in thread
From: Safa Hamza @ 2016-03-17 12:20 UTC (permalink / raw)
To: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]
i'm trying to run xen on omap5 and installing some guests .. it seems it
works and a xen boot dom0 as shown the screen shot
but with this arago project i can't download any package ..all commands
such as apt-get ,update ... are not found
i tried to have another file system but its not working ..
can you help me .. with which file system can i work
thanks
[-- Attachment #1.2: Type: text/html, Size: 437 bytes --]
[-- Attachment #2: dom0-boot.PNG --]
[-- Type: image/png, Size: 39281 bytes --]
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2016-02-25 12:38 Ayushi Arora
0 siblings, 0 replies; 170+ messages in thread
From: Ayushi Arora @ 2016-02-25 12:38 UTC (permalink / raw)
To: roger.pau; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]
Hello,
As asked of in the previous mail, I tried compiling Xen from source.
I am not sure whether we can ask questions for the task given, but I have
been stuck at it from yesterday.
I followed all the steps, and wherever there was some problem, I looked up
that in wiki of Xen, but after building and installing that with ovmf
enabled in ./configure, I moved on to the network configuration, and on
rebooting after the configuration, it is showing ' ERROR: Can't find
hypervisor information in sysfs!' on xm list and brctl shows no bridge
enabled. On further checking, it showed 'ERROR: Not running inside Xen'.
I have tried finding the problem, and I will check this again but I can't
move forward until the hypervisor runs!
Not sure where to check for the error.
Thank you,
Ayushi.
[-- Attachment #1.2: Type: text/html, Size: 933 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2015-12-07 17:27 Ian Jackson
0 siblings, 0 replies; 170+ messages in thread
From: Ian Jackson @ 2015-12-07 17:27 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Campbell
I'm intending to be able to do database schema updates. But I don't
want to play around with such code on a live database. So I need a
test database.
Thus, a yak: arrangements to make a test database.
As I say, I have tested this and it now does the right things in,
apparently, the right order, and seems to leave things in a good state
even when it collapses halfway or is ^C'd.
In v2 I have addressed the comments, and added a couple of new safety
catches. For ease of review these are mostly as followup patches to
the mg-schema-test-database script, rather than folded in.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2015-01-06 17:17 Konrad Rzeszutek Wilk
0 siblings, 0 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-01-06 17:17 UTC (permalink / raw)
To: xen-devel
I am proposing to put this in the 'staging-4.5' tree but would
appreciate an English speaker to take a look and make sure it
sounds good.
Thank you.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2014-12-19 9:53 Minalkumar Patel
2014-12-19 9:59 ` Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: Minalkumar Patel @ 2014-12-19 9:53 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 117 bytes --]
i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me
[-- Attachment #1.2: Type: text/html, Size: 359 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
@ 2014-02-13 23:47 Zir Blazer
0 siblings, 0 replies; 170+ messages in thread
From: Zir Blazer @ 2014-02-13 23:47 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]
>> I can't understand this as disk activity should be running on cores 0,>> 1 and 2, but never on core 3. The only thing running on core 3 should>> by my paravirtual machine and the hypervisor stub.>>>> Any idea what's going on?
Your Core i3 is a Dual Core Processor with Hyper Threading. Hyper Threading allows each Core to run two Threads simultaneously, in what is called physical Core and virtual Core (Or around those lines, but you get the idea). They share resources, and the extra Thread actually gets the free resources/execution time that weren't used by the main Thread. As Core 3 is the virtual core of the physical Core 2 (Assuming that on Linux it sees and numbers them as Physical Core 0, Logical Core 1, Physical Core 2 and Logical Core 3 and so on), you're giving that VM just a spare virtual Core with the free resources that weren't used by the physical Core. You should try with a full physical Core (Core 2 and 3), otherwise whatever runs on Core 2 WILL impact heavily what you see on Core 3.
[-- Attachment #1.2: Type: text/html, Size: 1401 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2014-02-13 16:01 Simon Martin
2014-02-13 16:10 ` Andrew Cooper
0 siblings, 1 reply; 170+ messages in thread
From: Simon Martin @ 2014-02-13 16:01 UTC (permalink / raw)
To: xen-devel
Hi all,
I am now successfully running my little operating system inside Xen.
It is fully preemptive and working a treat, but I have just noticed
something I wasn't expecting, and will really be a problem for me if
I can't work around it.
My configuration is as follows:
1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
2.- Xen: 4.4 (just pulled from repository)
3.- Dom0: Debian Wheezy (Kernel 3.2)
4.- 2 cpu pools:
# xl cpupool-list
Name CPUs Sched Active Domain count
Pool-0 3 credit y 2
pv499 1 arinc653 y 1
5.- 2 domU:
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 984 3 r----- 39.7
win7x64 1 2046 3 -b---- 143.0
pv499 3 128 1 -b---- 61.2
6.- All VCPUs are pinned:
# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 0 -b- 27.5 0
Domain-0 0 1 1 -b- 7.2 1
Domain-0 0 2 2 r-- 5.1 2
win7x64 1 0 0 -b- 71.6 0
win7x64 1 1 1 -b- 37.7 1
win7x64 1 2 2 -b- 34.5 2
pv499 3 0 3 -b- 62.1 3
7.- pv499 is the domU that I am testing. It has no disk or vif devices
(yet). I am running a little test program in pv499 and the timing I
see is varies depending on disk activity.
My test program runs prints up the time taken in milliseconds for a
million cycles. With no disk activity I see 940 ms, with disk activity
I see 1200 ms.
I can't understand this as disk activity should be running on cores 0,
1 and 2, but never on core 3. The only thing running on core 3 should
by my paravirtual machine and the hypervisor stub.
Any idea what's going on?
--
Best regards,
Simon mailto:furryfuttock@gmail.com
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2014-02-13 16:01 Simon Martin
@ 2014-02-13 16:10 ` Andrew Cooper
2014-02-13 17:27 ` Don Slutz
0 siblings, 1 reply; 170+ messages in thread
From: Andrew Cooper @ 2014-02-13 16:10 UTC (permalink / raw)
To: Simon Martin; +Cc: xen-devel
On 13/02/14 16:01, Simon Martin wrote:
> Hi all,
>
> I am now successfully running my little operating system inside Xen.
Congratulations!
> It is fully preemptive and working a treat, but I have just noticed
> something I wasn't expecting, and will really be a problem for me if
> I can't work around it.
>
> My configuration is as follows:
>
> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
Can you be more specific - this covers 4 generations of Intel CPUs.
>
> 2.- Xen: 4.4 (just pulled from repository)
>
> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>
> 4.- 2 cpu pools:
>
> # xl cpupool-list
> Name CPUs Sched Active Domain count
> Pool-0 3 credit y 2
> pv499 1 arinc653 y 1
>
> 5.- 2 domU:
>
> # xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 984 3 r----- 39.7
> win7x64 1 2046 3 -b---- 143.0
> pv499 3 128 1 -b---- 61.2
>
> 6.- All VCPUs are pinned:
>
> # xl vcpu-list
> Name ID VCPU CPU State Time(s) CPU Affinity
> Domain-0 0 0 0 -b- 27.5 0
> Domain-0 0 1 1 -b- 7.2 1
> Domain-0 0 2 2 r-- 5.1 2
> win7x64 1 0 0 -b- 71.6 0
> win7x64 1 1 1 -b- 37.7 1
> win7x64 1 2 2 -b- 34.5 2
> pv499 3 0 3 -b- 62.1 3
>
> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
> (yet). I am running a little test program in pv499 and the timing I
> see is varies depending on disk activity.
>
> My test program runs prints up the time taken in milliseconds for a
> million cycles. With no disk activity I see 940 ms, with disk activity
> I see 1200 ms.
>
> I can't understand this as disk activity should be running on cores 0,
> 1 and 2, but never on core 3. The only thing running on core 3 should
> by my paravirtual machine and the hypervisor stub.
>
> Any idea what's going on?
Curious. Lets try ruling some things out.
How are you measuring time in pv499?
What is your Cstates and Pstates looking like? If you can, try
disabling turbo?
~Andrew
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2014-02-13 16:10 ` Andrew Cooper
@ 2014-02-13 17:27 ` Don Slutz
0 siblings, 0 replies; 170+ messages in thread
From: Don Slutz @ 2014-02-13 17:27 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Simon Martin, xen-devel
On 02/13/14 11:10, Andrew Cooper wrote:
> On 13/02/14 16:01, Simon Martin wrote:
>> Hi all,
>>
>> I am now successfully running my little operating system inside Xen.
> Congratulations!
>
>> It is fully preemptive and working a treat, but I have just noticed
>> something I wasn't expecting, and will really be a problem for me if
>> I can't work around it.
>>
>> My configuration is as follows:
>>
>> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
> Can you be more specific - this covers 4 generations of Intel CPUs.
>
I think most i3's have Intel's hyper-threading. If this is a 2 core/4
thread chip, I would expect this kind of result. I also know that for
the "sandy bridge" version I am using:
Intel® Xeon® E3-1260L processors (“Sandy Bridge” microarchitecture)
(2.4/2.5/3.3 GHz, 4 cores/8 threads)
How many instruction per second a thread gets does depend on the
"idleness" of other threads (no longer just the hyperThread's parther).
For example running my test code that does:
0x0000000000400ee0 <workerMain+432>: inc %eax
0x0000000000400ee2 <workerMain+434>: cmp $0xffffffffffffffff,%eax
0x0000000000400ee5 <workerMain+437>: jne 0x400ee0 <workerMain+432>
for almost 4GiI in this loop.
On the setup:
[root@dcs-xen-53 ~]# xl cpupool-list
Name CPUs Sched Active Domain count
Pool-0 8 credit y 9
[root@dcs-xen-53 ~]# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 7 r-- 1033.2 any cpu
Domain-0 0 1 3 -b- 255.9 any cpu
Domain-0 0 2 2 -b- 451.7 any cpu
Domain-0 0 3 6 -b- 231.7 any cpu
Domain-0 0 4 3 -b- 197.0 any cpu
Domain-0 0 5 0 -b- 115.1 any cpu
Domain-0 0 6 0 -b- 69.9 any cpu
Domain-0 0 7 5 -b- 214.9 any cpu
P-1-0 2 0 0 -b- 73.6 0
P-1-2 4 0 2 -b- 46.5 2
P-1-3 5 0 3 -b- 44.6 3
P-1-4 6 0 4 -b- 38.1 4
P-1-5 7 0 5 -b- 41.3 5
P-1-6 8 0 6 -b- 38.6 6
P-1-7 9 0 7 -b- 40.6 7
P-1-1 10 0 1 -b- 35.3 1
(They are HVM not PV):
xentop - 17:20:57 Xen 4.3.2-rc1
9 domains: 2 running, 7 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2629 9.4 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 140 6.3 3145868 9.4 3146752 9.4 1 2 61 8 0 0 0 0 0 0 0
P-1-1 --b--- 101 6.1 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 113 6.3 3145868 9.4 3146752 9.4 1 2 96 10 0 0 0 0 0 0 0
P-1-3 --b--- 111 6.3 3145868 9.4 3146752 9.4 1 2 100 12 0 0 0 0 0 0 0
P-1-4 --b--- 61 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 90 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 --b--- 162 2.7 3145868 9.4 3146752 9.4 1 2 55 20 0 0 0 0 0 0 0
P-1-7 -----r 519 100.0 3145868 9.4 3146752 9.4 1 2 46 21 0 0 0 0 0 0 0
start done
thr 0: 13 Feb 14 12:20:54.201596 13 Feb 14 12:21:22.847245
+28.645649 ~= 28.65 and 4.19 GiI/Sec
And 6&7 at the same time:
xentop - 17:21:58 Xen 4.3.2-rc1
9 domains: 3 running, 6 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2633 6.1 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 144 6.2 3145868 9.4 3146752 9.4 1 2 63 8 0 0 0 0 0 0 0
P-1-1 --b--- 105 6.2 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 117 6.6 3145868 9.4 3146752 9.4 1 2 98 10 0 0 0 0 0 0 0
P-1-3 --b--- 115 6.5 3145868 9.4 3146752 9.4 1 2 103 12 0 0 0 0 0 0 0
P-1-4 --b--- 62 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 93 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 -----r 168 100.0 3145868 9.4 3146752 9.4 1 2 58 20 0 0 0 0 0 0 0
P-1-7 -----r 550 100.0 3145868 9.4 3146752 9.4 1 2 49 22 0 0 0 0 0 0 0
start done
thr 0: 13 Feb 14 12:21:55.073588 13 Feb 14 12:22:50.905476
+55.831888 ~= 55.83 and 2.15 GiI/Sec
start done
thr 0: 13 Feb 14 12:21:54.847626 13 Feb 14 12:22:49.206362
+54.358736 ~= 54.36 and 2.21 GiI/Sec
(The DomU are all CentOS 5.3, which why Dom0 is spending so much time
running QEMU.)
I would excpect the same from PV guests.
-Don Slutz
>> 2.- Xen: 4.4 (just pulled from repository)
>>
>> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>>
>> 4.- 2 cpu pools:
>>
>> # xl cpupool-list
>> Name CPUs Sched Active Domain count
>> Pool-0 3 credit y 2
>> pv499 1 arinc653 y 1
>>
>> 5.- 2 domU:
>>
>> # xl list
>> Name ID Mem VCPUs State Time(s)
>> Domain-0 0 984 3 r----- 39.7
>> win7x64 1 2046 3 -b---- 143.0
>> pv499 3 128 1 -b---- 61.2
>>
>> 6.- All VCPUs are pinned:
>>
>> # xl vcpu-list
>> Name ID VCPU CPU State Time(s) CPU Affinity
>> Domain-0 0 0 0 -b- 27.5 0
>> Domain-0 0 1 1 -b- 7.2 1
>> Domain-0 0 2 2 r-- 5.1 2
>> win7x64 1 0 0 -b- 71.6 0
>> win7x64 1 1 1 -b- 37.7 1
>> win7x64 1 2 2 -b- 34.5 2
>> pv499 3 0 3 -b- 62.1 3
>>
>> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
>> (yet). I am running a little test program in pv499 and the timing I
>> see is varies depending on disk activity.
>>
>> My test program runs prints up the time taken in milliseconds for a
>> million cycles. With no disk activity I see 940 ms, with disk activity
>> I see 1200 ms.
>>
>> I can't understand this as disk activity should be running on cores 0,
>> 1 and 2, but never on core 3. The only thing running on core 3 should
>> by my paravirtual machine and the hypervisor stub.
>>
>> Any idea what's going on?
> Curious. Lets try ruling some things out.
>
> How are you measuring time in pv499?
>
> What is your Cstates and Pstates looking like? If you can, try
> disabling turbo?
>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-12-31 15:15 Konrad Rzeszutek Wilk
0 siblings, 0 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-12-31 15:15 UTC (permalink / raw)
To: xen-devel, linux-kernel
This had been posted way way back: https://lkml.org/lkml/2013/1/16/696
and the discussion about it was:
- If there are no uses of v2, then why not rip out the support for it.
[b/c the work for it would be in the networking code and I am still
hoping that will be done?]
- Why not do all of this in the toolstack. Enforce that the guest
can only use v1 ".. if the backend isn't going to make use of them."
(Matt).
I am not sure how one would set up the plumbing to properly figure out
whether the backend (say a driver domain) would communicate to hypervisor
or XenBus that it is going to use v1 only if it has not yet started.
(It would not have started b/c the guest hasn't started yet).
My thinking is that once the frontend and backend start using the
esoteric features of v2 we can rip this patch out. And also implement
the proper code for PVHVM/PVH to actually use v2 grants.
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2013-12-17 18:35 Ian Jackson
2013-12-18 11:19 ` George Dunlap
0 siblings, 1 reply; 170+ messages in thread
From: Ian Jackson @ 2013-12-17 18:35 UTC (permalink / raw)
To: xen-devel
Cc: Shriram Rajagopalan, George Dunlap, Ian Campbell,
Stefano Stabellini
This series removes the usleeps and waiting loops in libxl_dom.c and
replaces them with event-callback code.
Firstly, some documentation of things I had to reverse-engineer:
01/23 xen: Document XEN_DOMCTL_subscribe
02/23 xen: Document that EVTCHNOP_bind_interdomain signals
03/23 docs: Document event-channel-based suspend protocol
04/23 libxc: Document xenctrl.h event channel calls
Arguably these might be 4.4 material (hence the CC to George).
We want some additional libxl event facilities:
05/23 libxl: init: Provide a gc later in libxl_ctx_alloc
06/23 libxl: init: libxl__poller_init and _get take gc
07/23 libxl: events: const-correct *_inuse, *_isregistered
08/23 libxl: events: Provide libxl__xswait_*
09/23 libxl: events: Use libxl__xswait_* in spawn code
10/23 libxl: events: Provide libxl__ev_evtchn*
We need to clean up some unfortunate code in libxc:
11/23 libxc: suspend: Rename, improve xc_suspend_evtchn_init
12/23 libxc: suspend: Fix suspend event channel locking
We do some shuffling around of the libxl suspend control flow:
13/23 libxl: suspend: Async libxl__domain_suspend_callback
14/23 libxl: suspend: Async domain_suspend_callback_common
15/23 libxl: suspend: Reorg domain_suspend_callback_common
16/23 libxl: suspend: New libxl__domain_pvcontrol_xspath
17/23 libxl: suspend: New domain_suspend_pvcontrol_acked
No functional change in those five. These changes are broken down
just to make the changes reviewable.
Finally, we can start to work on the event code, removing the bugs,
usleeps and loops one at a time:
18/23 libxl: suspend: domain_suspend_callback_common xs errs
19/23 libxl: suspend: Async xenstore pvcontrol wait
20/23 libxl: suspend: Abolish usleeps in domain suspend wait
21/23 libxl: suspend: Fix suspend wait corner cases
22/23 libxl: suspend: Async evtchn wait
23/23 libxl: suspend: Apply guest timeout in evtchn case
I have tested this with a Debian pvops kernel (xenstore pvcontrol
suspend signalling) and OpenSUSE 11 (event channel suspend
signalling).
Shriram: I haven't really touched the Remus-specific code here but
this series ought to be suitable for you to base things on, assuming
my co-maintainers like the general approach.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-12-17 18:35 Ian Jackson
@ 2013-12-18 11:19 ` George Dunlap
2013-12-18 13:35 ` Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: George Dunlap @ 2013-12-18 11:19 UTC (permalink / raw)
To: Ian Jackson, xen-devel
Cc: Shriram Rajagopalan, Ian Campbell, Stefano Stabellini
On 12/17/2013 06:35 PM, Ian Jackson wrote:
> This series removes the usleeps and waiting loops in libxl_dom.c and
> replaces them with event-callback code.
>
> Firstly, some documentation of things I had to reverse-engineer:
> 01/23 xen: Document XEN_DOMCTL_subscribe
> 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> 03/23 docs: Document event-channel-based suspend protocol
> 04/23 libxc: Document xenctrl.h event channel calls
> Arguably these might be 4.4 material (hence the CC to George).
These document pretty important aspects of behavior (fixing what might
be considered documentation bugs), and obviously can have no functional
impact. I guess the only risk is that they might be wrong and mislead
someone, but I think that's pretty low. :-)
These four:
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-12-18 11:19 ` George Dunlap
@ 2013-12-18 13:35 ` Ian Campbell
2014-01-07 13:55 ` Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: Ian Campbell @ 2013-12-18 13:35 UTC (permalink / raw)
To: George Dunlap
Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Stefano Stabellini
On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > This series removes the usleeps and waiting loops in libxl_dom.c and
> > replaces them with event-callback code.
> >
> > Firstly, some documentation of things I had to reverse-engineer:
> > 01/23 xen: Document XEN_DOMCTL_subscribe
> > 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> > 03/23 docs: Document event-channel-based suspend protocol
> > 04/23 libxc: Document xenctrl.h event channel calls
> > Arguably these might be 4.4 material (hence the CC to George).
>
> These document pretty important aspects of behavior (fixing what might
> be considered documentation bugs), and obviously can have no functional
> impact. I guess the only risk is that they might be wrong and mislead
> someone, but I think that's pretty low. :-)
>
> These four:
>
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
They look good to me too:
Acked-by: Ian Campbell <ian.campbell@citrix.com>
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-12-18 13:35 ` Ian Campbell
@ 2014-01-07 13:55 ` Ian Campbell
0 siblings, 0 replies; 170+ messages in thread
From: Ian Campbell @ 2014-01-07 13:55 UTC (permalink / raw)
To: George Dunlap
Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Stefano Stabellini
On Wed, 2013-12-18 at 13:35 +0000, Ian Campbell wrote:
> On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> > On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > > This series removes the usleeps and waiting loops in libxl_dom.c and
> > > replaces them with event-callback code.
> > >
> > > Firstly, some documentation of things I had to reverse-engineer:
> > > 01/23 xen: Document XEN_DOMCTL_subscribe
> > > 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> > > 03/23 docs: Document event-channel-based suspend protocol
> > > 04/23 libxc: Document xenctrl.h event channel calls
> > > Arguably these might be 4.4 material (hence the CC to George).
> >
> > These document pretty important aspects of behavior (fixing what might
> > be considered documentation bugs), and obviously can have no functional
> > impact. I guess the only risk is that they might be wrong and mislead
> > someone, but I think that's pretty low. :-)
> >
> > These four:
> >
> > Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> They look good to me too:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
And I've now applied just those 4 docs changes.
Ian.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-12-15 7:58 Adel Amani
0 siblings, 0 replies; 170+ messages in thread
From: Adel Amani @ 2013-12-15 7:58 UTC (permalink / raw)
To: Xen, Dario Faggioli
[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]
Hello
I attach tow pic of code and error.
I try to dirty_count in function of csched_credit.c calculate... :-( But I confront to error.
now can you help me?
Thanks.
Adel Amani
M.Sc. Candidate@Computer Engineering Department, University of Isfahan
Email: A.Amani@eng.ui.ac.ir
[-- Attachment #1.2: Type: text/html, Size: 2122 bytes --]
[-- Attachment #2: pic1.png --]
[-- Type: image/png, Size: 104979 bytes --]
[-- Attachment #3: pic2.JPG --]
[-- Type: image/jpeg, Size: 11865 bytes --]
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-11-13 19:02 Jim Durand
2013-11-18 14:17 ` George Dunlap
0 siblings, 1 reply; 170+ messages in thread
From: Jim Durand @ 2013-11-13 19:02 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --]
See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen 4.2.3. Perhaps we cannot live migrate across major revs?
[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:89) [xc_save]: /usr/lib64/xen/bin/xc_save 4 35 0 0 5
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Saving memory pages: iter 1 0%ERROR Internal error: Error when writing to state file (5) (errno 104)
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Save exit rc=1
[2013-11-13 11:49:00 xend 29149] ERROR (XendCheckpoint:133) Save failed on domain Pasiphae2 (35).
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 110, in save
forkHelper(cmd, fd, saveInputHandler, False)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 341, in forkHelper
raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_save 4 35 0 0 5 failed
[2013-11-13 11:49:00 xend.XendDomainInfo 29149] DEBUG (XendDomainInfo:2206) XendDomainInfo.resumeDomain(35)
[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:136) XendCheckpoint.save: resumeDomain
Thank you!
Jim
[-- Attachment #1.2: Type: text/html, Size: 3554 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2013-11-13 19:02 Jim Durand
@ 2013-11-18 14:17 ` George Dunlap
0 siblings, 0 replies; 170+ messages in thread
From: George Dunlap @ 2013-11-18 14:17 UTC (permalink / raw)
To: Jim Durand; +Cc: xen-devel@lists.xen.org
On Wed, Nov 13, 2013 at 7:02 PM, Jim Durand <jdurand@hrsg.ca> wrote:
> See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen
> 4.2.3. Perhaps we cannot live migrate across major revs?
According to http://wiki.xen.org/wiki/Xen_Version_Compatibility :
"Xen supports migration (including live migration and save restore)
both within a stable release branch (e.g. between any versions in the
4.2.x branch) and from one major release to the next (e.g. from
release N to releaseN+1). This allows one to upgrade a pool of Xen
hosts by evacuating and upgrading the hosts one by one.
"Although it is not formally supported skipping a major release (e.g.
migration from release N to release N+2) may often work. "
Unfortunately that would mean 3.1 -> 3.2 -> 3.3 -> 3.4 -> 4.0 -> 4.1
-> 4.2... at that point shutting down the VM and starting it back up
again looks like the more attractive option.
-George
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-09-13 16:59 David Vrabel
0 siblings, 0 replies; 170+ messages in thread
From: David Vrabel @ 2013-09-13 16:59 UTC (permalink / raw)
To: xen-devel; +Cc: Boris Ostrovsky, David Vrabel, Jan Beulich
This is an RFC of Linux guest-side implementation of the FIFO-based
event channel ABI described in this design document:
http://xenbits.xen.org/people/dvrabel/event-channels-E.pdf
Refer also to the Xen series.
Remaining work:
* Add an function to set a event channel's priority and use this to
set the VIRQ timer to the highest priority.
Patch 1 is a obvious refactoring of common code.
Patch 2-6 prepare for supporting multiple ABIs.
Patch 7 adds the low-level evtchn_ops hooks.
Patch 8-9 add an additional hook for ABI-specific per-port setup
(used for expanding the event array as more event are bound).
Patch 10 allows many more event channels to be supported by altering
how the event channel to irq map is allocated. Note that other
factors limit the number of supported IRQs (IRQs is 8192 + 64 *
NR_CPUS).
Patch 11 is some trival refactoring.
Patch 12-13 add the ABI and the implementation.
David
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-08-14 2:28 yvxiang
2013-08-14 2:31 ` yvxiang
2013-08-14 2:57 ` agya naila
0 siblings, 2 replies; 170+ messages in thread
From: yvxiang @ 2013-08-14 2:28 UTC (permalink / raw)
To: agya.naila; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 147 bytes --]
Hi,Agya,
Now I need to measure the downtime while doing a live migration. I saw your
mail before about this topic. How did you measure the time?
[-- Attachment #1.2: Type: text/html, Size: 191 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-08-14 2:28 yvxiang
@ 2013-08-14 2:31 ` yvxiang
2013-08-14 2:57 ` agya naila
1 sibling, 0 replies; 170+ messages in thread
From: yvxiang @ 2013-08-14 2:31 UTC (permalink / raw)
To: agya.naila; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]
So sorry,I forgot the subject..
2013/8/14 yvxiang <linyvxiang@gmail.com>
> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic. How did you measure the time?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
[-- Attachment #1.2: Type: text/html, Size: 829 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-08-14 2:28 yvxiang
2013-08-14 2:31 ` yvxiang
@ 2013-08-14 2:57 ` agya naila
1 sibling, 0 replies; 170+ messages in thread
From: agya naila @ 2013-08-14 2:57 UTC (permalink / raw)
To: yvxiang; +Cc: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]
Hi,
In my case I used the live migration for VoIP service. I make a simple
measurement by using wireshark, I generate the call and then shut down one
of my virtual machine. Then using packet captured via wireshark I generate
the jitter using telephony RTP stream anaysis. If you read the report you
may see the maximum delta that correlated to the downtime in my case for my
voip service.
Best Regards,
Agya
On Wed, Aug 14, 2013 at 9:28 AM, yvxiang <linyvxiang@gmail.com> wrote:
> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic. How did you measure the time?
>
[-- Attachment #1.2: Type: text/html, Size: 1207 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-07-04 11:32 Tim Deegan
2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: Tim Deegan @ 2013-07-04 11:32 UTC (permalink / raw)
To: Ian Campbell; +Cc: julien.grall, stefano.stabellini, xen-devel
Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
Reply-To:
In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>
At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> Everywhere currently passes "sy"stem, so no actual change.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
^ permalink raw reply [flat|nested] 170+ messages in thread
* [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
@ 2013-06-28 16:10 ` Ian Campbell
2013-07-04 11:44 ` (no subject) Tim Deegan
0 siblings, 1 reply; 170+ messages in thread
From: Ian Campbell @ 2013-06-28 16:10 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, tim, Ian Campbell, stefano.stabellini
Everywhere currently passes "sy"stem, so no actual change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
xen/arch/arm/domain.c | 2 +-
xen/arch/arm/gic.c | 8 ++++----
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/platforms/vexpress.c | 6 +++---
xen/arch/arm/smpboot.c | 2 +-
xen/arch/arm/time.c | 2 +-
xen/drivers/video/arm_hdlcd.c | 2 +-
xen/include/asm-arm/arm32/flushtlb.h | 8 ++++----
xen/include/asm-arm/arm32/io.h | 4 ++--
xen/include/asm-arm/arm32/page.h | 4 ++--
xen/include/asm-arm/arm64/io.h | 4 ++--
xen/include/asm-arm/arm64/page.h | 4 ++--
xen/include/asm-arm/page.h | 4 ++--
xen/include/asm-arm/system.h | 16 ++++++++--------
14 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4c434a1..0bd8f6b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -44,7 +44,7 @@ void idle_loop(void)
local_irq_disable();
if ( cpu_is_haltable(smp_processor_id()) )
{
- dsb();
+ dsb("sy");
wfi();
}
local_irq_enable();
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 177560e..42095ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -432,7 +432,7 @@ void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
ASSERT(mask < 0x100); /* The target bitmap only supports 8 CPUs */
- dsb();
+ dsb("sy");
GICD[GICD_SGIR] = GICD_SGI_TARGET_LIST
| (mask<<GICD_SGI_TARGET_SHIFT)
@@ -449,7 +449,7 @@ void send_SGI_self(enum gic_sgi sgi)
{
ASSERT(sgi < 16); /* There are only 16 SGIs */
- dsb();
+ dsb("sy");
GICD[GICD_SGIR] = GICD_SGI_TARGET_SELF
| sgi;
@@ -459,7 +459,7 @@ void send_SGI_allbutself(enum gic_sgi sgi)
{
ASSERT(sgi < 16); /* There are only 16 SGIs */
- dsb();
+ dsb("sy");
GICD[GICD_SGIR] = GICD_SGI_TARGET_OTHERS
| sgi;
@@ -546,7 +546,7 @@ static int __setup_irq(struct irq_desc *desc, unsigned int irq,
desc->action = new;
desc->status &= ~IRQ_DISABLED;
- dsb();
+ dsb("sy");
desc->handler->startup(desc);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 3f049cb..b287a9b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -324,7 +324,7 @@ void __cpuinit setup_virt_paging(void)
#define WRITE_TTBR(ttbr) \
flush_xen_text_tlb(); \
WRITE_SYSREG64(ttbr, TTBR0_EL2); \
- dsb(); /* ensure memory accesses do not cross over the TTBR0 write */ \
+ dsb("sy"); /* ensure memory accesses do not cross over the TTBR0 write */ \
/* flush_xen_text_tlb contains an initial isb which ensures the \
* write to TTBR0 has completed. */ \
flush_xen_text_tlb()
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
index 8fc30c4..6f6869e 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -46,7 +46,7 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
/* wait for complete flag to be set */
do {
stat = syscfg[V2M_SYS_CFGSTAT/4];
- dsb();
+ dsb("sy");
} while ( !(stat & V2M_SYS_CFG_COMPLETE) );
/* check error status and return error flag if set */
@@ -111,10 +111,10 @@ static void vexpress_reset(void)
/* switch to slow mode */
iowritel(sp810, 0x3);
- dsb(); isb();
+ dsb("sy"); isb();
/* writing any value to SCSYSSTAT reg will reset the system */
iowritel(sp810 + 4, 0x1);
- dsb(); isb();
+ dsb("sy"); isb();
iounmap(sp810);
}
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 727e09f..b88355f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -211,7 +211,7 @@ void stop_cpu(void)
local_irq_disable();
cpu_is_dead = 1;
/* Make sure the write happens before we sleep forever */
- dsb();
+ dsb("sy");
isb();
while ( 1 )
wfi();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 4ed7882..2c254f4 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -252,7 +252,7 @@ void udelay(unsigned long usecs)
s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
while ( get_s_time() - deadline < 0 )
;
- dsb();
+ dsb("sy");
isb();
}
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
index 72979ea..5c09b0e 100644
--- a/xen/drivers/video/arm_hdlcd.c
+++ b/xen/drivers/video/arm_hdlcd.c
@@ -77,7 +77,7 @@ void (*video_puts)(const char *) = vga_noop_puts;
static void hdlcd_flush(void)
{
- dsb();
+ dsb("sy");
}
static int __init get_color_masks(const char* bpp, struct color_masks **masks)
diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
index 14e8827..2776375 100644
--- a/xen/include/asm-arm/arm32/flushtlb.h
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -4,22 +4,22 @@
/* Flush local TLBs, current VMID only */
static inline void flush_tlb_local(void)
{
- dsb();
+ dsb("sy");
WRITE_CP32((uint32_t) 0, TLBIALLIS);
- dsb();
+ dsb("sy");
isb();
}
/* Flush local TLBs, all VMIDs, non-hypervisor mode */
static inline void flush_tlb_all_local(void)
{
- dsb();
+ dsb("sy");
WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
- dsb();
+ dsb("sy");
isb();
}
diff --git a/xen/include/asm-arm/arm32/io.h b/xen/include/asm-arm/arm32/io.h
index ec7e0ff..cb0bc96 100644
--- a/xen/include/asm-arm/arm32/io.h
+++ b/xen/include/asm-arm/arm32/io.h
@@ -30,14 +30,14 @@ static inline uint32_t ioreadl(const volatile void __iomem *addr)
asm volatile("ldr %1, %0"
: "+Qo" (*(volatile uint32_t __force *)addr),
"=r" (val));
- dsb();
+ dsb("sy");
return val;
}
static inline void iowritel(const volatile void __iomem *addr, uint32_t val)
{
- dsb();
+ dsb("sy");
asm volatile("str %1, %0"
: "+Qo" (*(volatile uint32_t __force *)addr)
: "r" (val));
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index e573502..f8dfbd3 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -67,13 +67,13 @@ static inline void flush_xen_data_tlb(void)
static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
{
unsigned long end = va + size;
- dsb(); /* Ensure preceding are visible */
+ dsb("sy"); /* Ensure preceding are visible */
while ( va < end ) {
asm volatile(STORE_CP32(0, TLBIMVAHIS)
: : "r" (va) : "memory");
va += PAGE_SIZE;
}
- dsb(); /* Ensure completion of the TLB flush */
+ dsb("sy"); /* Ensure completion of the TLB flush */
isb();
}
diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index ec041cd..0a100ad 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -24,14 +24,14 @@ static inline uint32_t ioreadl(const volatile void __iomem *addr)
uint32_t val;
asm volatile("ldr %w0, [%1]" : "=r" (val) : "r" (addr));
- dsb();
+ dsb("sy");
return val;
}
static inline void iowritel(const volatile void __iomem *addr, uint32_t val)
{
- dsb();
+ dsb("sy");
asm volatile("str %w0, [%1]" : : "r" (val), "r" (addr));
}
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 28748d3..aca1590 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -60,13 +60,13 @@ static inline void flush_xen_data_tlb(void)
static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
{
unsigned long end = va + size;
- dsb(); /* Ensure preceding are visible */
+ dsb("sy"); /* Ensure preceding are visible */
while ( va < end ) {
asm volatile("tlbi vae2is, %0;"
: : "r" (va>>PAGE_SHIFT) : "memory");
va += PAGE_SIZE;
}
- dsb(); /* Ensure completion of the TLB flush */
+ dsb("sy"); /* Ensure completion of the TLB flush */
isb();
}
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index cd38956..eb007ac 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -284,10 +284,10 @@ extern size_t cacheline_bytes;
static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
{
void *end;
- dsb(); /* So the CPU issues all writes to the range */
+ dsb("sy"); /* So the CPU issues all writes to the range */
for ( end = p + size; p < end; p += cacheline_bytes )
asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
- dsb(); /* So we know the flushes happen before continuing */
+ dsb("sy"); /* So we know the flushes happen before continuing */
}
/* Macro for flushing a single small item. The predicate is always
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 89c61ef..68efba9 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -13,16 +13,16 @@
#define wfi() asm volatile("wfi" : : : "memory")
#define isb() asm volatile("isb" : : : "memory")
-#define dsb() asm volatile("dsb sy" : : : "memory")
-#define dmb() asm volatile("dmb sy" : : : "memory")
+#define dsb(scope) asm volatile("dsb " scope : : : "memory")
+#define dmb(scope) asm volatile("dmb " scope : : : "memory")
-#define mb() dsb()
-#define rmb() dsb()
-#define wmb() dsb()
+#define mb() dsb("sy")
+#define rmb() dsb("sy")
+#define wmb() dsb("sy")
-#define smp_mb() dmb()
-#define smp_rmb() dmb()
-#define smp_wmb() dmb()
+#define smp_mb() dmb("sy")
+#define smp_rmb() dmb("sy")
+#define smp_wmb() dmb("sy")
#define xchg(ptr,x) \
((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
--
1.7.2.5
^ permalink raw reply related [flat|nested] 170+ messages in thread* Re: (no subject)
2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
@ 2013-07-04 11:44 ` Tim Deegan
0 siblings, 0 replies; 170+ messages in thread
From: Tim Deegan @ 2013-07-04 11:44 UTC (permalink / raw)
To: Ian Campbell; +Cc: julien.grall, xen-devel, stefano.stabellini
Oops, a wandering newline seems to have got into the headers here. :)
Tim.
At 12:32 +0100 on 04 Jul (1372941166), Tim Deegan wrote:
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
> Reply-To:
> In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>
>
> At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> > Everywhere currently passes "sy"stem, so no actual change.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> Acked-by: Tim Deegan <tim@xen.org>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-06-26 11:42 Divya Kapil
2013-06-26 11:54 ` Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: Divya Kapil @ 2013-06-26 11:42 UTC (permalink / raw)
To: xen-devel
How can i change migration code in xen?
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-06-16 13:45 wei.liu2
0 siblings, 0 replies; 170+ messages in thread
From: wei.liu2 @ 2013-06-16 13:45 UTC (permalink / raw)
We would like you to answer the following questions (feel free to
write up your own report if you're a power user):
* What's the sotware setup?
* Dom0: e.g. 64 bit CentOS 6.2
* DomU: e.g. Debian Wheezy
* Xen: e.g. 4.1 installed with apt-get / 4.2 compiled from tarball
* toolstack: xl / xm / libvirt ...
* What's the hardware setup?
* What were you trying to achieve?
* What commands did you run?
* What's the expected outcome?
* What's the actual outcome?
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-05-14 15:11 Feng Tang
0 siblings, 0 replies; 170+ messages in thread
From: Feng Tang @ 2013-05-14 15:11 UTC (permalink / raw)
To: David Vrabel, John Stultz
Cc: Thomas Gleixner, Konrad Rzeszutek Wilk,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Bcc:
Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes
Reply-To:
Hi David,
> From: David Vrabel <david.vrabel@citrix.com>
> Date: 2013/5/14
> Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on
> system time step changes
> To: John Stultz <john.stultz@linaro.org>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Konrad
> Rzeszutek Wilk <konrad.wilk@oracle.com>, Thomas Gleixner
> <tglx@linutronix.de>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
>
>
> On 14/05/13 01:40, John Stultz wrote:
> > On 05/13/2013 10:56 AM, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The persistent clock or the RTC is only synchronized with system time
> >> every 11 minutes if NTP is running. This gives a window where the
> >> persistent clock may be incorrect after a step change in the time
> >> (such as on first boot).
> >>
> >> This particularly affects Xen guests as until an update to the control
> >> domain's persistent clock, new guests will start with the incorrect
> >> system time.
> >>
> >> When there is a step change in the system time, call
> >> update_persistent_clock or rtc_set_ntp_time() to synchronize the
> >> persistent clock or RTC to the new system time.
> >
> > I'm sorry, this isn't quite making sense to me. Could you further
> > describe the exact problematic behavior you're seeing here, and why its
> > a problem?
>
> The Xen wallclock is used as the persistent clock for Xen guests. This
> is initialized (by Xen) with the CMOS RTC at the start of day. If the
> RTC is incorrect then guests will see an incorrect wallclock time until
> dom0 has corrected it.
>
> Currently dom0 only updates the Xen wallclock with the 11 min periodic
> work when NTP is synced. This leaves a window where newly started
> guests will see an incorrect wallclock time. This can cause guests to
> fail to start correctly if the wallclock is now behind what it was when
> the guest last started. (e.g., fsck of its disk fails as its last mount
> time appears to be far into the future).
Is it possible for Xen to resync its wallclock time from the RTC device
whenever it gets a request of starting a new guest? as usually a new
guest OS needs to get the time base from Xen's wallclock anyway.
Thanks,
Feng
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-05-03 8:48 Lars Kurth
0 siblings, 0 replies; 170+ messages in thread
From: Lars Kurth @ 2013-05-03 8:48 UTC (permalink / raw)
To: xen-api@lists.xen.org, xen-users@lists.xen.org,
xen-devel@lists.xen.org
Cc: Kimihiko.Kitase
[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]
> Subject: Looking for volunteer to help man LinuxCon Japan booth (1-2 hours
> a day)
>
> Dear Community member,
>
> the Xen Project was planning to have a booth at LinuxCon Japan this year
> (for more information, see
> http://events.linuxfoundation.org/events/linuxcon-japan/<https://mail.citrix.com/owa/redir.aspx?C=dnbPGSChGEWoACoWH_QLpH7EveZxG9BIE6cabrXu0jA-wgQqxbnVAgQREizU60s78z6uEa6Tkac.&URL=http%3a%2f%2fevents.linuxfoundation.org%2fevents%2flinuxcon-japan%2f>).
We are
> looking for one or two users (or developers of Xen) to help out a couple
> of hours a day on the Xen Project booth. I am looking for people who know
> Xen, XAPI or XCP, speak Japanese and want to spend an hour or two a day
> on the booth with me and a few other community members. If this is you,
> please get in touch!
>
> I will be able to get you a free conference pass for LinuxCon. If this is
> you and you would like to attend LinuxCon, but cannot afford it, we do
have
> a number of travel stipends available. In that case, please also send me
> an e-mail.
>
> Best Regards
> Lars
-----
みなさま、こんにちは
The Xen Community ManagerのLars Kurthです。
The Xen Projectコミュニティでは、5/29 - 31 椿山荘で開催されるLinuxCon Japan / CloudOpen Japan
にて展示ブースを出す予定です。
https://events.linuxfoundation.jp/events/linuxcon-japan
https://events.linuxfoundation.jp/events/cloudopen-japan
そこで展示ブーススタッフを募集しています。OSS Xenの開発者、ユーザー、
その他関連各位で、半日でも、１日でもお時間が取れる方がいらっしゃれば
ご連絡いただければと思います。
もちろん、ブーススタッフとして協力いただける方には、
LinuxCon Japan / CloudOpen Japan のFree Passチケットをお渡しします。
よろしくお願いいたします。
連絡先
Lars Kurth lars.kurth@citrix.com (英語)
Kimihiko Kitase Kimihiko.Kitase@citrix.co.jp (日本語)
[-- Attachment #1.2: Type: text/html, Size: 8578 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-04-21 22:26 Lonnie Cumberland
0 siblings, 0 replies; 170+ messages in thread
From: Lonnie Cumberland @ 2013-04-21 22:26 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]
Greetings All,
I am very new to Xen but have spent a considerable amount of time
researching various emulators and simulators like QEMU, Virtualbox, Bochs,
etc.... to find out which may be good for a project that I am interested in
moving towards related to the x86_64 platform.
It seems that XEN may be the best solution as I need something that can be
billed as a Type I and also Type II emulator. Xen and HXen meet these goals.
Now I am entering the learning curve to get a feel for the source code but
had a question related to the layout of Xen.
I am trying to understand where the main init functions are in Xen as for
example in QEMU they are in the v1.c file and as to where the mian loops
are for the hypervisor are to loop through the vCPU's.
I am also trying to get a feel for where the memory allocation functions
are in Xen.
Also, in the Xen 4.2.1 distro, is qemu called for each HPV.
Please forgive these questions if they should be obvious to me, but I would
like to get a good feel for the booting sequence and control loops that Xen
has to utilize.
I have read a number of documents on the website that give me briev
overview of how Xen operates with Dom0 and DomU guests but now it is time
for me to get a feel for the sources so that I might be able to learn and
contribute to the effort of a very wonderful hypervisor.
Any guidance or help would be greatly appreciated.
Kind Regards and have a great day,
Lonnie T. Cumberland
[-- Attachment #1.2: Type: text/html, Size: 1866 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
[parent not found: <CAHyyzzTtK+LbxOh2r_X0=Zd2FsTxoAiLLaWahv5FY-QZnQxhLQ@mail.gmail.com>]
* (no subject)
@ 2013-04-10 6:57 Mina Jafari
0 siblings, 0 replies; 170+ messages in thread
From: Mina Jafari @ 2013-04-10 6:57 UTC (permalink / raw)
To: xen-users, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3275 bytes --]
I can't install any guest vm,(I'm trying this on Fedora13 and kernel
3.2.7,compiled as dom0 and xen 4.1.2)
virt-manager connect to xen but when trying to create a new guest it
fails with this error:
Unable to complete install: 'POST operation failed: xend_post: error
from xen daemon: (xend.err 'Device 0 (vif) could not be connected.
Hotplug scripts not working.')'
operation failed: xend_post: error from xen daemon: (xend.err 'Device
0 (vif) could not be connected. Hotplug scripts not working.')
Traceback (most recent call last):
File "/usr/share/virt-manager/
virtManager/create.py", line 1567, in
do_install
dom = guest.start_install(False, meter = meter)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1023, in start_install
return self._do_install(consolecb, meter, removeOld, wait)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1088, in _do_install
"install")
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1059, in _create_guest
dom = self.conn.createLinux(start_xml, 0)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1277, in
createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Device 0 (vif) could not be connected. Hotplug scripts not
working.')
and the same problem when creating by commandline.
I'v set up a bridge:
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0024e8e7bd75 no eth0
virbr0 8000.000000000000 yes
ifcfg-br0 file :
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=yes
ifconfig
br0 Link encap:Ethernet HWaddr 00:24:E8:E7:BD:75
inet6 addr: fe80::224:e8ff:fee7:bd75/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:554 (554.0 b)
eth0 Link encap:Ethernet HWaddr 00:24:E8:E7:BD:75
UP BROADCAST MULTICAST MTU:9000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:36 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:131950 errors:0 dropped:0 overruns:0 frame:0
TX packets:131950 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15243838 (14.5 MiB) TX bytes:15243838 (14.5 MiB)
virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:#.#.#.# Bcast:#.#.#.# Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[-- Attachment #1.2: Type: text/html, Size: 3829 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2013-03-15 7:40 digvijay chauhan
2013-03-15 9:59 ` Ian Campbell
2013-03-15 11:18 ` Pasi Kärkkäinen
0 siblings, 2 replies; 170+ messages in thread
From: digvijay chauhan @ 2013-03-15 7:40 UTC (permalink / raw)
To: xen-users, xen-devel, xen-devel, Ian Campbell, Christian Limpach
[-- Attachment #1.1: Type: text/plain, Size: 627 bytes --]
Hello,
I am trying to install xen4.2 but when ifire make tools command
it gives me,
Cloning into 'seabios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out
make[3]: *** [seabios-dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
make: *** [install-tools] Error 2
so how can i overcome it.
regards,
DigvijaySingh
[-- Attachment #1.2: Type: text/html, Size: 842 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2013-03-15 7:40 digvijay chauhan
@ 2013-03-15 9:59 ` Ian Campbell
2013-03-15 11:18 ` Pasi Kärkkäinen
1 sibling, 0 replies; 170+ messages in thread
From: Ian Campbell @ 2013-03-15 9:59 UTC (permalink / raw)
To: digvijay chauhan
Cc: xen-users@lists.xen.org, Christian Limpach,
xen-devel@lists.xensource.com, xen-devel@lists.xen.org
Digvijay,
You have cross posted this message to multiple lists I have already
asked you not to do this on at least one occasion.
You have also CCd various people, including myself, seemingly at random,
*and* posted the same message three times in quick succession.
Please stop this antisocial behaviour.
Post to a single list (xen-users@ in the common case for the sorts of
questions you are asking) and wait a reasonable amount of time (i.e.
measured in days) for a response before pinging.
Ian.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-03-15 7:40 digvijay chauhan
2013-03-15 9:59 ` Ian Campbell
@ 2013-03-15 11:18 ` Pasi Kärkkäinen
1 sibling, 0 replies; 170+ messages in thread
From: Pasi Kärkkäinen @ 2013-03-15 11:18 UTC (permalink / raw)
To: digvijay chauhan
Cc: xen-users, Christian Limpach, xen-devel, Ian Campbell, xen-devel
On Fri, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote:
> Hello,
> I am trying to install xen4.2 but when ifire make tools
> command it gives me,
>
> Cloning into 'seabios-dir-remote.tmp'...
> fatal: unable to connect to [1]xenbits.xen.org:
> [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out
>
So maybe your firewall is blocking the connection?
-- Pasi
> make[3]: *** [seabios-dir] Error 128
> make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
> firmware'
> make[2]: *** [subdir-install-firmware] Error 2
> make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
> make: *** [install-tools] Error 2
>
> so how can i overcome it.
>
> regards,
> DigvijaySingh
>
> References
>
> Visible links
> 1. http://xenbits.xen.org/
> 2. http://xenbits.xen.org/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2013-01-08 21:51 Rushikesh Jadhav
0 siblings, 0 replies; 170+ messages in thread
From: Rushikesh Jadhav @ 2013-01-08 21:51 UTC (permalink / raw)
To: xen-api@lists.xen.org, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]
Hello List,
Please help me in diagnosing below error in /var/log/messages
HVM1[16586]: txftrans.c:4498 -- TXF_HARD_ERROR (0xC01A002B) for RM:
fffff8800d099000
Im unable to find any google reference related to above C file or its
source code. http://lmgtfy.com/?q=txftrans.c
Thanks for reading and helping.
Regards,
Rushikesh
[-- Attachment #1.2: Type: text/html, Size: 484 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-11-15 12:08 Tim Deegan
2012-11-15 23:04 ` Aravindh Puthiyaparambil
2013-04-22 21:56 ` Cutter 409
0 siblings, 2 replies; 170+ messages in thread
From: Tim Deegan @ 2012-11-15 12:08 UTC (permalink / raw)
To: Cutter 409; +Cc: Aravindh Puthiyaparambil, xen-devel
Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] Guest memory access hooking
Reply-To:
In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
Hi,
At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> I'm trying to do some research with malware, and I'm trying to get
> notifications on arbitrary guest page accesses (similar to what Ether
> does.) I've noticed the mem-event API and it seems like it might be close
> to what I need, but I can't find much documentation about how it works or
> how to use it.
Yes, the mem-event api, and in particular the HVMOP_set_mem_access
hypercall, looks like what you want. As you say, there isn't much
documentation for it, except the xen-access.c client and the mailing
list archive.
CC'ing Aravindh, who has worked on this code most recently and might be
able to help with specific questions.
> I know that that mem-event API works only with EPT, but is the code to
> change permissions modifying the guest page tables, or does it work via
> EPT? (Can the guest detect it?)
It works by EPT. The guest can't detect it by looking at its pagetables
or page fault patterns, though it might be able to detect it by looking
at timings.
> I'm also interested monitoring arbitrary page access via the shadow page
> tables. I've been reading through the code, but if anyone has any insight
> or some kind of push in the right direction, I'd really appreciate it.
Your best bet is to modify _sh_propagate. Look at how it handles
shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
shadow PTE is made read-only until the guest is actually doing a write,
then mark_dirty can be called. You should be able to do the same thing
for other kinds of access.
Cheers,
Tim.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-11-15 12:08 Tim Deegan
@ 2012-11-15 23:04 ` Aravindh Puthiyaparambil
2013-04-22 21:56 ` Cutter 409
1 sibling, 0 replies; 170+ messages in thread
From: Aravindh Puthiyaparambil @ 2012-11-15 23:04 UTC (permalink / raw)
To: Tim Deegan; +Cc: xen-devel@lists.xensource.com, Cutter 409
On Thu, Nov 15, 2012 at 4:08 AM, Tim Deegan <tim@xen.org> wrote:
>
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want. As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.
Sure, I can help with the specifics of the API usage.
> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT. The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.
It might be useful to get mem-event working with shadow by following
Tim's suggestions to achieve what you are after.
Thanks,
Aravindh
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-11-15 12:08 Tim Deegan
2012-11-15 23:04 ` Aravindh Puthiyaparambil
@ 2013-04-22 21:56 ` Cutter 409
2013-04-23 8:49 ` Tim Deegan
1 sibling, 1 reply; 170+ messages in thread
From: Cutter 409 @ 2013-04-22 21:56 UTC (permalink / raw)
To: Tim Deegan; +Cc: Aravindh Puthiyaparambil, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3206 bytes --]
Hi,
I'm finally to a point where I can start looking at this more closely. I'm
trying to wrap my head around the shadow code to figure out the right
course of action.
I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
things to work via p2m somehow. I think I understand this part.
* HVMOP_set_mem_access is used to change the p2m_access_t for the target
page(s). This should already be implemented I think?
* During propagation, I'll check the p2m map to see if I should mask off
any permission bits.
* On a shadow paging fault, I'll check if the fault was caused by p2m
permissions, somehow integrating that with the code for read-only guest
page tables safely.
Questions:
* Just for background, am I correct in my understanding that the log_dirty
code is used to track which gfns have been written to by the guest, in
order to speed up migration?
* Are multiple shadow tables maintained per domain? Is there one per VCPU?
One shadow table per guest page table? Is it blown away every time the
guest changes CR3? I'm having some trouble tracking this down.
* How should I clear/update existing shadow entries after changing the
p2m_access_t? Can I clear the shadow tables somehow and force everything to
be repopulated? Is that insane?
Thanks!
On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xen.org> wrote:
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <
> CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want. As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.
>
> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT. The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.
>
> Your best bet is to modify _sh_propagate. Look at how it handles
> shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
> shadow PTE is made read-only until the guest is actually doing a write,
> then mark_dirty can be called. You should be able to do the same thing
> for other kinds of access.
>
> Cheers,
>
> Tim.
>
[-- Attachment #1.2: Type: text/html, Size: 4078 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2013-04-22 21:56 ` Cutter 409
@ 2013-04-23 8:49 ` Tim Deegan
0 siblings, 0 replies; 170+ messages in thread
From: Tim Deegan @ 2013-04-23 8:49 UTC (permalink / raw)
To: Cutter 409; +Cc: Aravindh Puthiyaparambil, xen-devel
Hi,
At 17:56 -0400 on 22 Apr (1366653364), Cutter 409 wrote:
> I'm finally to a point where I can start looking at this more closely. I'm
> trying to wrap my head around the shadow code to figure out the right
> course of action.
>
> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
> things to work via p2m somehow. I think I understand this part.
>
> * HVMOP_set_mem_access is used to change the p2m_access_t for the target
> page(s). This should already be implemented I think?
Yep. The shadow code uses the same p2m implementataion as NPT, so that
should all be fine.
> * During propagation, I'll check the p2m map to see if I should mask off
> any permission bits.
Yep. You'll already be doing a p2m lookup to get the MFN, so you just
need to look at the p2ma as well.
> * On a shadow paging fault, I'll check if the fault was caused by p2m
> permissions, somehow integrating that with the code for read-only guest
> page tables safely.
Yes. The common case will be handled in _sh_propagate, which is where
the shadow PTE is constructed. For the rest you'll need to look at the
places where the shadow fault handler calls the emulator and DTRT
(either before the call or in the callbacks that the emulator uses to
access guest memory).
> Questions:
>
> * Just for background, am I correct in my understanding that the log_dirty
> code is used to track which gfns have been written to by the guest, in
> order to speed up migration?
That's right. It's also used to track which parts of an emulated
framebuffer have been updated, to make VNC connections more efficient.
> * Are multiple shadow tables maintained per domain? Is there one per VCPU?
> One shadow table per guest page table? Is it blown away every time the
> guest changes CR3? I'm having some trouble tracking this down.
There's one set of shadows per domain, shared among all VCPUs. A given
page of memory may have multiple shadows though, e.g. if it's seen both
as a top-level pagetables and a leaf pagetable.
Shadows are kept around until:
- it looks like the page is no longer a pagetable;
- the guest explicitly tells us it's no longer a pagetable; or
- we need the memory to shadow some other page.
Mostly, a pages's shadow(s) are kept in sync with any changes the guest
makes to the page, by trapping and emulating all writes. For
performance, we allow some l1 pagetables to be 'out of sync' ('oos' in
the code), letting the guest write to the page directly. On guest CR3
writes (and other TLB-flush-related activity) we make sure any OOS
shadows are brought up to date.
> * How should I clear/update existing shadow entries after changing the
> p2m_access_t? Can I clear the shadow tables somehow and force everything to
> be repopulated? Is that insane?
It depends how often you're changing the access permissions.
sh_remove_all_mappings() and sh_remove_write_access() will try to flush
mappings of a single MFN from the shadows, but they can be expensive
(e.g. involving a brute-force scan of all shadows) so if you're going to
do a lot of them it may be worth considering batching them up and
calling shadow_blow_tables() once instead.
Cheers,
Tim.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-07-27 23:02 lmw
0 siblings, 0 replies; 170+ messages in thread
From: lmw @ 2012-07-27 23:02 UTC (permalink / raw)
To: xen-devel
What is the easiest way to determine the Dom Id of a unmodified Xen HVM guest from within a daemon process running in the guest?
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-07-14 4:16 张智
2012-07-19 10:24 ` Tim Deegan
0 siblings, 1 reply; 170+ messages in thread
From: 张智 @ 2012-07-14 4:16 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 168 bytes --]
Hi, list,
Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.
All the very best,Henry
[-- Attachment #1.2: Type: text/html, Size: 844 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-04-15 6:09 Lin Ming
0 siblings, 0 replies; 170+ messages in thread
From: Lin Ming @ 2012-04-15 6:09 UTC (permalink / raw)
To: linux-kernel
Cc: Jeremy Fitzhardinge, Peter Zijlstra, Konrad Rzeszutek Wilk,
Steven Noonan, Marcus Granado, xen-devel, Ben Guthro
Hi all,
These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506
I tested it with 3.4-rc2 and "perf top" works well now.
Steven,
Could you please help to test it too?
The soft lockup code path is:
__irq_work_queue
arch_irq_work_raise
apic->send_IPI_self(IRQ_WORK_VECTOR);
apic_send_IPI_self
__default_send_IPI_shortcut
__xapic_wait_icr_idle
static inline void __xapic_wait_icr_idle(void)
{
while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
cpu_relax();
}
The lockup happens at above while looop.
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.
So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.
Ben Guthro (1):
xen: implement apic ipi interface
Lin Ming (1):
xen: implement IRQ_WORK_VECTOR handler
arch/x86/include/asm/xen/events.h | 1 +
arch/x86/xen/enlighten.c | 7 ++
arch/x86/xen/smp.c | 111 +++++++++++++++++++++++++++++++++++-
arch/x86/xen/smp.h | 12 ++++
4 files changed, 127 insertions(+), 4 deletions(-)
Any comment is appreciated.
Lin Ming
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2012-04-05 18:26 Francisco Rocha
2012-04-05 19:36 ` Wei Huang
0 siblings, 1 reply; 170+ messages in thread
From: Francisco Rocha @ 2012-04-05 18:26 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel@lists.xen.org
Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"
On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco
What is your Linux command line? does it include "console=hvc0"?
Perhaps some early_printk settings are required.
Please include my email in your replies, thank you.
Yes, it includes hvc0. I used your tutorial to setup the SOL.
title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root (hd0,0)
kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module /initrd-2.6.31.6.img
Something like this, I am not at the machine anymore.
Francisco
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-05 18:26 Francisco Rocha
@ 2012-04-05 19:36 ` Wei Huang
2012-04-05 20:17 ` Francisco Rocha
0 siblings, 1 reply; 170+ messages in thread
From: Wei Huang @ 2012-04-05 19:36 UTC (permalink / raw)
To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel@lists.xen.org
On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root (hd0,0)
> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.
-Wei
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-05 19:36 ` Wei Huang
@ 2012-04-05 20:17 ` Francisco Rocha
2012-04-05 20:27 ` Wei Huang
0 siblings, 1 reply; 170+ messages in thread
From: Francisco Rocha @ 2012-04-05 20:17 UTC (permalink / raw)
To: wei.huang2@amd.com; +Cc: Andrew Cooper, xen-devel@lists.xen.org
________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)
On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root (hd0,0)
> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.
-Wei
Sorry about the untitled message.
Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?
Anyway, shouldn't Xen support it?
cheers,
Francisco
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-05 20:17 ` Francisco Rocha
@ 2012-04-05 20:27 ` Wei Huang
2012-04-05 20:43 ` Francisco Rocha
0 siblings, 1 reply; 170+ messages in thread
From: Wei Huang @ 2012-04-05 20:27 UTC (permalink / raw)
To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel@lists.xen.org
On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root (hd0,0)
>> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:
kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah
-Wei
>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-05 20:27 ` Wei Huang
@ 2012-04-05 20:43 ` Francisco Rocha
2012-04-06 14:53 ` Francisco Rocha
0 siblings, 1 reply; 170+ messages in thread
From: Francisco Rocha @ 2012-04-05 20:43 UTC (permalink / raw)
To: wei.huang2@amd.com; +Cc: Andrew Cooper, xen-devel@lists.xen.org
________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)
On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root (hd0,0)
>> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:
kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah
Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
Thank you for the help.
Francisco
-Wei
>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-05 20:43 ` Francisco Rocha
@ 2012-04-06 14:53 ` Francisco Rocha
2012-04-06 14:51 ` Wei Huang
0 siblings, 1 reply; 170+ messages in thread
From: Francisco Rocha @ 2012-04-06 14:53 UTC (permalink / raw)
To: wei.huang2@amd.com; +Cc: Andrew Cooper, xen-devel@lists.xen.org
________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)
________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)
On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root (hd0,0)
>> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:
kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah
Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
Thank you for the help.
Francisco
-Wei
>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco
The xsave=0 command line parameter solves the problem.
Thank you,
Francisco
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-06 14:53 ` Francisco Rocha
@ 2012-04-06 14:51 ` Wei Huang
2012-04-06 15:02 ` Francisco Rocha
2012-04-06 15:14 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 170+ messages in thread
From: Wei Huang @ 2012-04-06 14:51 UTC (permalink / raw)
To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel@lists.xen.org
Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.
-Wei
On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root (hd0,0)
>>> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-06 14:51 ` Wei Huang
@ 2012-04-06 15:02 ` Francisco Rocha
2012-04-06 15:14 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 170+ messages in thread
From: Francisco Rocha @ 2012-04-06 15:02 UTC (permalink / raw)
To: wei.huang2@amd.com; +Cc: Andrew Cooper, xen-devel@lists.xen.org
________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)
Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.
-Wei
I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both
rebooted the machine.
Cheers,
Francisco
On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root (hd0,0)
>>> kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-06 14:51 ` Wei Huang
2012-04-06 15:02 ` Francisco Rocha
@ 2012-04-06 15:14 ` Konrad Rzeszutek Wilk
2012-04-06 16:09 ` Francisco Rocha
1 sibling, 1 reply; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-06 15:14 UTC (permalink / raw)
To: Wei Huang; +Cc: Francisco Rocha, xen-devel@lists.xen.org, Andrew Cooper
On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.
Hm .
.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.
Francisco,
What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2012-04-06 15:14 ` Konrad Rzeszutek Wilk
@ 2012-04-06 16:09 ` Francisco Rocha
0 siblings, 0 replies; 170+ messages in thread
From: Francisco Rocha @ 2012-04-06 16:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Wei Huang; +Cc: Andrew Cooper, xen-devel@lists.xen.org
________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)
On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.
Hm .
.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.
Francisco,
What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.
I downloaded the latest version from xen-unstable.hg yesterday.
My machine is a Toshiba laptop R840-12F. Here is some info:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping : 7
microcode : 0x25
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5382.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
BIOS: TOSHIBA
Version: Version 3.60
Release Date: 01/24/2012
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-02-24 18:54 Ian Jackson
0 siblings, 0 replies; 170+ messages in thread
From: Ian Jackson @ 2012-02-24 18:54 UTC (permalink / raw)
To: xen-devel
Once again, I have not executed the code in this series!
These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
01/15 libxl: ao: allow immediate completion
02/15 libxl: fix hang due to libxl__initiate_device_remove
These are other bugfixes:
03/15 libxl: Fix eventloop_iteration over-locking
04/15 libxl: Fix leak of ctx->lock
05/15 libxl: abolish libxl_ctx_postfork
06/15 tools: Correct PTHREAD options in config/StdGNU.mk
07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
08/15 libxl: Crash (more sensibly) on malloc failure
These are handy new bits for internal libxl users:
09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
10/15 libxl: Introduce some convenience macros
11/15 libxl: Protect fds with CLOEXEC even with forking threads
12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
14/15 libxl: Provide libxl_string_list_length
15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
This is the new child-handling machinery:
13/15 libxl: event API: new facilities for waiting for subprocesses
There are not any users for much of this code in this series. I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage. It doesn't even
compile.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2012-02-17 19:15 Ian Jackson
0 siblings, 0 replies; 170+ messages in thread
From: Ian Jackson @ 2012-02-17 19:15 UTC (permalink / raw)
To: xen-devel
>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To:
This is the first draft of my new libxl API for child process
handling.
1/6 libxl: Fix leak of ctx->lock
2/6 libxl: abolish libxl_ctx_postfork
3/6 tools: Correct PTHREAD options in config/StdGNU.mk
4/6 libxl: Protect fds with CLOEXEC even with forking threads
5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
6/6 libxl: event API: new facilities for waiting for subprocesses
Please comment. I'm particularly keen on comments about:
* The correctness of the pthread_atfork logic in 4/6.
* The sufficiency for applications of the child handling API in 6/6.
* The portability of the pthread command line option changes in 3/6.
* Correctness :-).
If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-10-17 7:40 Paolo Bonzini
2011-10-17 17:05 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 170+ messages in thread
From: Paolo Bonzini @ 2011-10-17 7:40 UTC (permalink / raw)
To: xen-devel
Writing [PATCH] netback: disable features not supported by netfront ...
ntent-Transfer-Encoding: 7bit
Subject: [PATCH] netback: disable features not supported by netfront
X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 17 Oct 2011 09:37:42 +0200
From: pbonzini@redhat.com
To: pbonzini@redhat.com
# HG changeset patch
# User Paolo Bonzini <pbonzini@redhat.com>
# Date 1318837036 -7200
# Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
# Parent 3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
netback: disable features not supported by netfront
Netback works by first setting all possible features, and then
resetting some after connection, if the front-end didn't negotiate them.
Except that in the old 2.6.18 tree the "resetting" part was missing.
In the pvops tree, this should work correctly through the fix_features
mechanism.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
void netif_set_features(netif_t *netif)
{
struct net_device *dev = netif->dev;
- int features = dev->features;
+ int features;
+ features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
if (netif->can_sg)
features |= NETIF_F_SG;
if (netif->gso)
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2011-10-17 7:40 Paolo Bonzini
@ 2011-10-17 17:05 ` Konrad Rzeszutek Wilk
2011-10-17 21:02 ` Ian Campbell
2011-10-18 7:13 ` Paolo Bonzini
0 siblings, 2 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-10-17 17:05 UTC (permalink / raw)
To: Paolo Bonzini, Ian Campbell; +Cc: xen-devel
On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
Something went wrong with your patchbomb..
anyhow, lets CC Ian here since he is the maintainer.
>
> Writing [PATCH] netback: disable features not supported by netfront ...
> ntent-Transfer-Encoding: 7bit
> Subject: [PATCH] netback: disable features not supported by netfront
> X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> User-Agent: Mercurial-patchbomb/1.9.1
> Date: Mon, 17 Oct 2011 09:37:42 +0200
> From: pbonzini@redhat.com
> To: pbonzini@redhat.com
>
> # HG changeset patch
> # User Paolo Bonzini <pbonzini@redhat.com>
> # Date 1318837036 -7200
> # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> # Parent 3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> netback: disable features not supported by netfront
>
> Netback works by first setting all possible features, and then
> resetting some after connection, if the front-end didn't negotiate them.
> Except that in the old 2.6.18 tree the "resetting" part was missing.
> In the pvops tree, this should work correctly through the fix_features
> mechanism.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>
> diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
> void netif_set_features(netif_t *netif)
> {
> struct net_device *dev = netif->dev;
> - int features = dev->features;
> + int features;
>
> + features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
> if (netif->can_sg)
> features |= NETIF_F_SG;
> if (netif->gso)
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2011-10-17 17:05 ` Konrad Rzeszutek Wilk
@ 2011-10-17 21:02 ` Ian Campbell
2011-10-18 7:13 ` Paolo Bonzini
1 sibling, 0 replies; 170+ messages in thread
From: Ian Campbell @ 2011-10-17 21:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Paolo Bonzini, xen-devel@lists.xensource.com
On Mon, 2011-10-17 at 18:05 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
>
> Something went wrong with your patchbomb..
>
> anyhow, lets CC Ian here since he is the maintainer.
This is a 2.6.18-xen patch. I'm not especially interested in that tree
-- Jan looks after it though and picked up this patch from the resend.
Ian.
>
> >
> > Writing [PATCH] netback: disable features not supported by netfront ...
> > ntent-Transfer-Encoding: 7bit
> > Subject: [PATCH] netback: disable features not supported by netfront
> > X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> > Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> > User-Agent: Mercurial-patchbomb/1.9.1
> > Date: Mon, 17 Oct 2011 09:37:42 +0200
> > From: pbonzini@redhat.com
> > To: pbonzini@redhat.com
> >
> > # HG changeset patch
> > # User Paolo Bonzini <pbonzini@redhat.com>
> > # Date 1318837036 -7200
> > # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> > # Parent 3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> > netback: disable features not supported by netfront
> >
> > Netback works by first setting all possible features, and then
> > resetting some after connection, if the front-end didn't negotiate them.
> > Except that in the old 2.6.18 tree the "resetting" part was missing.
> > In the pvops tree, this should work correctly through the fix_features
> > mechanism.
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> > --- a/drivers/xen/netback/interface.c
> > +++ b/drivers/xen/netback/interface.c
> > @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
> > void netif_set_features(netif_t *netif)
> > {
> > struct net_device *dev = netif->dev;
> > - int features = dev->features;
> > + int features;
> >
> > + features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
> > if (netif->can_sg)
> > features |= NETIF_F_SG;
> > if (netif->gso)
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2011-10-17 17:05 ` Konrad Rzeszutek Wilk
2011-10-17 21:02 ` Ian Campbell
@ 2011-10-18 7:13 ` Paolo Bonzini
1 sibling, 0 replies; 170+ messages in thread
From: Paolo Bonzini @ 2011-10-18 7:13 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Ian Campbell, xen-devel
On 10/17/2011 07:05 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
>
> Something went wrong with your patchbomb..
>
> anyhow, lets CC Ian here since he is the maintainer.
Already resent, and acked by Jan. :)
Paolo
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-10-06 13:11 Pratik shinde
2011-10-06 13:18 ` Andrew Cooper
0 siblings, 1 reply; 170+ messages in thread
From: Pratik shinde @ 2011-10-06 13:11 UTC (permalink / raw)
To: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 44 bytes --]
why coscheduling is not implemented in xen?
[-- Attachment #1.2: Type: text/html, Size: 48 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-07-27 8:33 Grant McWilliams
0 siblings, 0 replies; 170+ messages in thread
From: Grant McWilliams @ 2011-07-27 8:33 UTC (permalink / raw)
To: afb, linux-poweredge, david.lane, support, BronsonLK, xen-devel,
arnaud.sumien, LarsonK
http://succeedonpurpose.com/google.php
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-06-21 3:39 Attila Jecs
2011-06-21 13:20 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 170+ messages in thread
From: Attila Jecs @ 2011-06-21 3:39 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]
Hi!
well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3
Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
0xffffffff815cd65f()
Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
Jun 21 05:18:02 szerver kernel: Modules linked in:
Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
#8
Jun 21 05:18:02 szerver kernel: Call Trace:
Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
Jun 21 05:18:02 szerver kernel: ... version: 0
Jun 21 05:18:02 szerver kernel: ... bit width: 48
Jun 21 05:18:02 szerver kernel: ... generic registers: 4
Jun 21 05:18:02 szerver kernel: ... value mask: 0000ffffffffffff
Jun 21 05:18:02 szerver kernel: ... max period: 00007fffffffffff
Jun 21 05:18:02 szerver kernel: ... fixed-purpose events: 0
Jun 21 05:18:02 szerver kernel: ... event mask: 000000000000000f
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
Jun 21 05:18:02 szerver kernel: devtmpfs: initialized
maybe it helps.
if u need more info, just tell me
--
Attila Jecs
[-- Attachment #1.2: Type: text/html, Size: 3237 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2011-06-21 3:39 Attila Jecs
@ 2011-06-21 13:20 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 170+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-06-21 13:20 UTC (permalink / raw)
To: Attila Jecs; +Cc: xen-devel
On Tue, Jun 21, 2011 at 05:39:46AM +0200, Attila Jecs wrote:
> Hi!
>
> well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3
Thank you.
That is a benign error. Does it continue booting?
>
> Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
> Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
> Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
> Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
> Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
> Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
> Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
> Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
> Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
> 0xffffffff815cd65f()
> Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
> Jun 21 05:18:02 szerver kernel: Modules linked in:
> Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
> #8
> Jun 21 05:18:02 szerver kernel: Call Trace:
> Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
> Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
> Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
> Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
> Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
> Jun 21 05:18:02 szerver kernel: ... version: 0
> Jun 21 05:18:02 szerver kernel: ... bit width: 48
> Jun 21 05:18:02 szerver kernel: ... generic registers: 4
> Jun 21 05:18:02 szerver kernel: ... value mask: 0000ffffffffffff
> Jun 21 05:18:02 szerver kernel: ... max period: 00007fffffffffff
> Jun 21 05:18:02 szerver kernel: ... fixed-purpose events: 0
> Jun 21 05:18:02 szerver kernel: ... event mask: 000000000000000f
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
> Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
> Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
> Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
> Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
> Jun 21 05:18:02 szerver kernel: devtmpfs: initialized
>
> maybe it helps.
> if u need more info, just tell me
> --
> Attila Jecs
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-04-04 6:18 Novik, Alex
0 siblings, 0 replies; 170+ messages in thread
From: Novik, Alex @ 2011-04-04 6:18 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]
Hi, all.
How do I activate the battery management in pass-through mode? XEN 4.1, platform Lenovo.
Thanks in advance,
Alex Novik.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2011-03-20 22:27 Keshav Darak
0 siblings, 0 replies; 170+ messages in thread
From: Keshav Darak @ 2011-03-20 22:27 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, keir
[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]
We have implemented hugepage support for guests in following manner
In
our implementation we added a parameter hugepage_num which is specified
in the config file of the DomU. It is the number of hugepages that the
guest is guaranteed to receive whenever the kernel asks for hugepage by
using its boot time parameter or reserving after booting (eg. Using echo
XX > /proc/sys/vm/nr_hugepages). During creation of the domain we
reserve MFN's for these hugepages and store them in the list. The
listhead of this list is inside the domain structure with name
"hugepage_list". When the domain is booting, at that time the memory
seen by the kernel is allocated memory less the amount required for hugepages. The function
reserve_hugepage_range is called as a initcall. Before this function the
xen_extra_mem_start points to this apparent end of the memory. In this
function we reserve the PFN range for the hugepages which are going to
be allocated by kernel by incrementing the xen_extra_mem_start. We
maintain these PFNs as pages in "xen_hugepfn_list" in the kernel.
Now before the kernel requests for hugepages, it makes a hypercall HYPERVISOR_memory_op to get count of hugepages allocated to it and accordingly reserves the pfn range.
then whenever kernel requests for hugepages it again make hypercall HYPERVISOR_memory_op to get the preallocated hugepage and according makes the p2m mapping on both sides (xen as well as kernel side)
The approach can be better explained using the presentation attached.
--
Keshav Darak
[-- Attachment #1.2: Type: text/html, Size: 1742 bytes --]
[-- Attachment #2: xen_patch_210311_0227.patch --]
[-- Type: application/x-download, Size: 18234 bytes --]
[-- Attachment #3: jeremy-kernel.patch --]
[-- Type: application/x-download, Size: 6731 bytes --]
[-- Attachment #4: our_hugepage_approach.ppt --]
[-- Type: application/vnd.ms-powerpoint, Size: 327168 bytes --]
[-- Attachment #5: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2010-11-16 11:12 Ken Ash
0 siblings, 0 replies; 170+ messages in thread
From: Ken Ash @ 2010-11-16 11:12 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
h
Sent from my iPhone
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2010-10-07 2:46 Mike Viau
2010-10-07 10:43 ` Stefano Stabellini
2010-10-07 14:02 ` Ian Campbell
0 siblings, 2 replies; 170+ messages in thread
From: Mike Viau @ 2010-10-07 2:46 UTC (permalink / raw)
To: xen-devel
I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
Thanks.
-Mike Viau
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2010-10-07 2:46 Mike Viau
@ 2010-10-07 10:43 ` Stefano Stabellini
2010-10-07 13:43 ` George Shuklin
2010-10-07 14:02 ` Ian Campbell
1 sibling, 1 reply; 170+ messages in thread
From: Stefano Stabellini @ 2010-10-07 10:43 UTC (permalink / raw)
To: Mike Viau; +Cc: xen-devel@lists.xensource.com
On Thu, 7 Oct 2010, Mike Viau wrote:
>
> I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
>
> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
>
> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
>
We intend to publish debian and centos packages for the xen hypervisor
and tools, however the project is stalling a bit recently.
Hopefully those packages will be published in the next few weeks.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2010-10-07 10:43 ` Stefano Stabellini
@ 2010-10-07 13:43 ` George Shuklin
2010-10-07 14:21 ` Ian Campbell
0 siblings, 1 reply; 170+ messages in thread
From: George Shuklin @ 2010-10-07 13:43 UTC (permalink / raw)
Cc: xen-devel
Please note this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
This behavior confirmed in lenny and squeeze. Kernel is very unstable
(compare to centos/suse) and cause OOM killer without any rational
reason.
В Чтв, 07/10/2010 в 11:43 +0100, Stefano Stabellini пишет:
> On Thu, 7 Oct 2010, Mike Viau wrote:
> >
> > I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> >
> > http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> >
> > I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> >
>
> We intend to publish debian and centos packages for the xen hypervisor
> and tools, however the project is stalling a bit recently.
> Hopefully those packages will be published in the next few weeks.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2010-10-07 13:43 ` George Shuklin
@ 2010-10-07 14:21 ` Ian Campbell
2010-10-07 16:54 ` George Shuklin
0 siblings, 1 reply; 170+ messages in thread
From: Ian Campbell @ 2010-10-07 14:21 UTC (permalink / raw)
To: George Shuklin; +Cc: xen-devel@lists.xensource.com
On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> Please note this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
>
> This behavior confirmed in lenny and squeeze. Kernel is very unstable
> (compare to centos/suse) and cause OOM killer without any rational
> reason.
I wasn't aware that this issue was present on Squeeze as well as Lenny,
there is no mention of that in the bug.
The two kernels have practically nothing in common wrt the Xen port
(Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
are seeing something similar under Squeeze as well please file a
separate bug report.
(Note that only the OS in the specific VM which is exhibiting the
problem is relevant, so even if you are seeing the issue with a Lenny VM
hosted on a Squeeze dom0 that does not imply the bug is present in
Squeeze).
I'm afraid that at this point I do not have cycles to spend on the Lenny
issue. Unfortunately my best recommendation is not to balloon such
systems too aggressively or to use a more recent kernel (e.g. a backport
of the Squeeze kernel).
Ian.
--
Ian Campbell
Current Noise: Twisted Sister - Tear It Loose
Other restrictions may apply.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2010-10-07 14:21 ` Ian Campbell
@ 2010-10-07 16:54 ` George Shuklin
0 siblings, 0 replies; 170+ messages in thread
From: George Shuklin @ 2010-10-07 16:54 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
В Чтв, 07/10/2010 в 15:21 +0100, Ian Campbell пишет:
> On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> > Please note this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> >
> > This behavior confirmed in lenny and squeeze. Kernel is very unstable
> > (compare to centos/suse) and cause OOM killer without any rational
> > reason.
>
> I wasn't aware that this issue was present on Squeeze as well as Lenny,
> there is no mention of that in the bug.
>
> The two kernels have practically nothing in common wrt the Xen port
> (Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
> are seeing something similar under Squeeze as well please file a
> separate bug report.
OK, I'll recheck bug in squeeze and report it separately.
Main problem for this bug is very high value of free memory when OOM
killer starts. In my tests it appear when about 300MiB was free. And it
kill not most 'badness' process, but runs repeatedly for few (or even
all) process.
But, again, I'll recheck it in clean environment with reproducible
behavior and submit it.
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2010-10-07 2:46 Mike Viau
2010-10-07 10:43 ` Stefano Stabellini
@ 2010-10-07 14:02 ` Ian Campbell
1 sibling, 0 replies; 170+ messages in thread
From: Ian Campbell @ 2010-10-07 14:02 UTC (permalink / raw)
To: Mike Viau; +Cc: xen-devel@lists.xensource.com
On Thu, 2010-10-07 at 03:46 +0100, Mike Viau wrote:
> I have search the archives for reference to Ian Campbell's Debian
> binaries found at: http://xenbits.xen.org/people/ianc/
> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%
> 2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!
> &idxname=xen-devel&max=20&result=normal&sort=score
They were posted on my personal website
http://www.hellion.org.uk/debian/test/
and referred to by
http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01912.html
but I moved them to xen.org and just left a pointer on my website, I
didn't bother to announce this.
> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or
> http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way
> be added to Debian's apt sources file?
I'm afraid the necessary meta data is not present to allow them to be
used as an apt source so they are download+dpkg only.
Originally they were intended to simply verify that the issues people
were seeing related to changesets which had been excluded from the
Debian kernel.
I haven't decided if these are something I necessarily want to maintain
for the lifetime of Squeeze. For the moment I build them for my own
personal use and so I publish them, since I might as well do so, but
they are not a formal xen.org service or anything like that.
For something provided by xen.org I think we would more likely want to
track the latest xen.git#xen/stable-2.6.x.y branch rather than the
Debian packages.
Ian.
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2010-04-16 10:59 Jiang, Yunhong
0 siblings, 0 replies; 170+ messages in thread
From: Jiang, Yunhong @ 2010-04-16 10:59 UTC (permalink / raw)
To: Keir Fraser, Christoph Egger, Frank.Vanderlinden@Sun.COM
Cc: xen-devel@lists.xensource.com, Ke, Liping
[-- Attachment #1: Type: text/plain, Size: 10984 bytes --]
Add a x86_mcinfo_reserve() function, to reserve space from mc_info.
With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.
Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.
It's meaningless to get the current information in mce context, keep it here
but should be removed in future.
Also a flag added to mc_info, to indicate some information is lost due to OOM.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
mc_need_clearbank_scan = cbfunc;
}
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+ struct mc_info *mi, int bank)
+{
+ struct mcinfo_bank *mib;
+ uint64_t addr=0, misc = 0;
+
+ if (!mi)
+ return NULL;
+
+ mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+ if (!mib)
+ {
+ mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+ return NULL;
+ }
+
+ memset(mib, 0, sizeof (struct mcinfo_bank));
+ mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+ mib->common.type = MC_TYPE_BANK;
+ mib->common.size = sizeof (struct mcinfo_bank);
+ mib->mc_bank = bank;
+
+ addr = misc = 0;
+ if (mib->mc_status & MCi_STATUS_MISCV)
+ mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+ if (mib->mc_status & MCi_STATUS_ADDRV)
+ {
+ mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+ if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+ struct domain *d;
+
+ d = maddr_get_owner(mib->mc_addr);
+ if (d != NULL && (who == MCA_POLLER ||
+ who == MCA_CMCI_HANDLER))
+ mib->mc_domid = d->domain_id;
+ }
+ }
+
+ if (who == MCA_CMCI_HANDLER) {
+ mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+ rdtscll(mib->mc_tsc);
+ }
+
+ return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+ uint64_t status;
+ int cpu_nr;
+ struct vcpu *v = current;
+ struct domain *d;
+
+ /* Set global information */
+ memset(mig, 0, sizeof (struct mcinfo_global));
+ mig->common.type = MC_TYPE_GLOBAL;
+ mig->common.size = sizeof (struct mcinfo_global);
+ mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+ mig->mc_gstatus = status;
+ mig->mc_domid = mig->mc_vcpuid = -1;
+ mig->mc_flags = flags;
+ cpu_nr = smp_processor_id();
+ /* Retrieve detector information */
+ x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+ &mig->mc_coreid, &mig->mc_core_threadid,
+ &mig->mc_apicid, NULL, NULL, NULL);
+
+ /* This is really meaningless */
+ if (v != NULL && ((d = v->domain) != NULL)) {
+ mig->mc_domid = d->domain_id;
+ mig->mc_vcpuid = v->vcpu_id;
+ } else {
+ mig->mc_domid = -1;
+ mig->mc_vcpuid = -1;
+ }
+
+ return 0;
+}
+
/* Utility function to perform MCA bank telemetry readout and to push that
* telemetry towards an interested dom0 for logging and diagnosis.
* The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum
mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
struct mca_summary *sp, cpu_banks_t* clear_bank)
{
- struct vcpu *v = current;
- struct domain *d;
- uint64_t gstatus, status, addr, misc;
- struct mcinfo_global mcg; /* on stack */
- struct mcinfo_common *mic;
- struct mcinfo_global *mig; /* on stack */
+ uint64_t gstatus, status;
+ struct mcinfo_global *mig = NULL; /* on stack */
mctelem_cookie_t mctc = NULL;
- uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+ uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
struct mc_info *mci = NULL;
mctelem_class_t which = MC_URGENT; /* XXXgcc */
- unsigned int cpu_nr;
int errcnt = 0;
int i;
enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
- cpu_nr = smp_processor_id();
- BUG_ON(cpu_nr != v->processor);
-
mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
- memset(&mcg, 0, sizeof (mcg));
- mcg.common.type = MC_TYPE_GLOBAL;
- mcg.common.size = sizeof (mcg);
- if (v != NULL && ((d = v->domain) != NULL)) {
- mcg.mc_domid = d->domain_id;
- mcg.mc_vcpuid = v->vcpu_id;
- } else {
- mcg.mc_domid = -1;
- mcg.mc_vcpuid = -1;
- }
- mcg.mc_gstatus = gstatus; /* MCG_STATUS */
-
switch (who) {
case MCA_MCE_HANDLER:
case MCA_MCE_SCAN:
- mcg.mc_flags = MC_FLAG_MCE;
+ mc_flags = MC_FLAG_MCE;
which = MC_URGENT;
break;
case MCA_POLLER:
case MCA_RESET:
- mcg.mc_flags = MC_FLAG_POLLED;
+ mc_flags = MC_FLAG_POLLED;
which = MC_NONURGENT;
break;
case MCA_CMCI_HANDLER:
- mcg.mc_flags = MC_FLAG_CMCI;
+ mc_flags = MC_FLAG_CMCI;
which = MC_NONURGENT;
break;
default:
BUG();
}
-
- /* Retrieve detector information */
- x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
- &mcg.mc_coreid, &mcg.mc_core_threadid,
- &mcg.mc_apicid, NULL, NULL, NULL);
/* If no mc_recovery_scan callback handler registered,
* this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum
recover = (mc_recoverable_scan)? 1: 0;
for (i = 0; i < 32 && i < nr_mce_banks; i++) {
- struct mcinfo_bank mcb; /* on stack */
+ struct mcinfo_bank *mib; /* on stack */
/* Skip bank if corresponding bit in bankmask is clear */
if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum
* a poller; this can fail (for example dom0 may not
* yet have consumed past telemetry). */
if (errcnt == 0) {
- if ((mctc = mctelem_reserve(which)) != NULL) {
+ if ( (mctc = mctelem_reserve(which)) != NULL ) {
mci = mctelem_dataptr(mctc);
mcinfo_clear(mci);
+ mig = (struct mcinfo_global*)x86_mcinfo_reserve
+ (mci, sizeof(struct mcinfo_global));
+ /* mc_info should at least hold up the global information */
+ ASSERT(mig);
+ mca_init_global(mc_flags, mig);
}
}
-
- memset(&mcb, 0, sizeof (mcb));
- mcb.common.type = MC_TYPE_BANK;
- mcb.common.size = sizeof (mcb);
- mcb.mc_bank = i;
- mcb.mc_status = status;
/* form a mask of which banks have logged uncorrected errors */
if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum
*/
recover = mc_recoverable_scan(status);
- addr = misc = 0;
-
- if (status & MCi_STATUS_ADDRV) {
- mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
- if (mfn_valid(paddr_to_pfn(addr))) {
- d = maddr_get_owner(addr);
- if (d != NULL && (who == MCA_POLLER ||
- who == MCA_CMCI_HANDLER))
- mcb.mc_domid = d->domain_id;
- }
- }
-
- if (status & MCi_STATUS_MISCV)
- mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
- mcb.mc_addr = addr;
- mcb.mc_misc = misc;
-
- if (who == MCA_CMCI_HANDLER) {
- mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
- rdtscll(mcb.mc_tsc);
- }
-
- /* Increment the error count; if this is the first bank
- * with a valid error then add the global info to the mcinfo. */
- if (errcnt++ == 0 && mci != NULL)
- x86_mcinfo_add(mci, &mcg);
-
- /* Add the bank data */
- if (mci != NULL)
- x86_mcinfo_add(mci, &mcb);
+ mib = mca_init_bank(who, mci, i);
if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum
wmb();
}
- if (mci != NULL && errcnt > 0) {
- x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
- mig = container_of(mic, struct mcinfo_global, common);
- if (mic == NULL)
- ;
- else if (pcc)
+ if (mig && errcnt > 0) {
+ if (pcc)
mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
else if (uc)
mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info
x86_mcinfo_nentries(mi) = 0;
}
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
{
int i;
unsigned long end1, end2;
- struct mcinfo_common *mic, *mic_base, *mic_index;
-
- mic = (struct mcinfo_common *)mcinfo;
+ struct mcinfo_common *mic_base, *mic_index;
+
mic_index = mic_base = x86_mcinfo_first(mi);
/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
/* check if there is enough size */
end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
- end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+ end2 = (unsigned long)((uint8_t *)mic_index + size);
if (end1 < end2)
- return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+ {
+ mce_printk(MCE_CRITICAL,
+ "mcinfo_add: No space left in mc_info\n");
+ return NULL;
+ }
/* there's enough space. add entry. */
- memcpy(mic_index, mic, mic->size);
x86_mcinfo_nentries(mi)++;
- return 0;
+ return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+ struct mcinfo_common *mic, *buf;
+
+ mic = (struct mcinfo_common *)mcinfo;
+ buf = x86_mcinfo_reserve(mi, mic->size);
+
+ if ( !buf )
+ mce_printk(MCE_CRITICAL,
+ "mcinfo_add: No space left in mc_info\n");
+ else
+ memcpy(buf, mic, mic->size);
+
+ return buf;
}
/* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
(struct mc_info *, uint16_t, uint64_t);
extern void x86_mce_callback_register(x86_mce_callback_t);
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
void x86_mcinfo_dump(struct mc_info *mi);
int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
#define MCINFO_HYPERCALLSIZE 1024
#define MCINFO_MAXSIZE 768
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
struct mc_info {
/* Number of mcinfo_* entries in mi_data */
uint32_t mi_nentries;
- uint32_t _pad0;
+ uint32_t flags;
uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
};
typedef struct mc_info mc_info_t;
[-- Attachment #2: mcinfo_reserve.patch --]
[-- Type: application/octet-stream, Size: 10822 bytes --]
# HG changeset patch
# User Yunhong Jiang <yunhong.jiang@intel.com>
# Date 1271415118 -28800
# Node ID 63632454170a30f4e0cbffa78be62b33e87605bb
# Parent 4e1d1e56e8b90f8594db6f812b5bd5f35f6e87be
Add a x86_mcinfo_reserve() function, to reserve space from mc_info.
With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.
Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.
It's meaningless to get the current information in mce context, keep it here
but should be removed in future.
Also a flag added to mc_info, to indicate some information is lost due to OOM.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
mc_need_clearbank_scan = cbfunc;
}
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+ struct mc_info *mi, int bank)
+{
+ struct mcinfo_bank *mib;
+ uint64_t addr=0, misc = 0;
+
+ if (!mi)
+ return NULL;
+
+ mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+ if (!mib)
+ {
+ mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+ return NULL;
+ }
+
+ memset(mib, 0, sizeof (struct mcinfo_bank));
+ mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+ mib->common.type = MC_TYPE_BANK;
+ mib->common.size = sizeof (struct mcinfo_bank);
+ mib->mc_bank = bank;
+
+ addr = misc = 0;
+ if (mib->mc_status & MCi_STATUS_MISCV)
+ mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+ if (mib->mc_status & MCi_STATUS_ADDRV)
+ {
+ mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+ if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+ struct domain *d;
+
+ d = maddr_get_owner(mib->mc_addr);
+ if (d != NULL && (who == MCA_POLLER ||
+ who == MCA_CMCI_HANDLER))
+ mib->mc_domid = d->domain_id;
+ }
+ }
+
+ if (who == MCA_CMCI_HANDLER) {
+ mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+ rdtscll(mib->mc_tsc);
+ }
+
+ return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+ uint64_t status;
+ int cpu_nr;
+ struct vcpu *v = current;
+ struct domain *d;
+
+ /* Set global information */
+ memset(mig, 0, sizeof (struct mcinfo_global));
+ mig->common.type = MC_TYPE_GLOBAL;
+ mig->common.size = sizeof (struct mcinfo_global);
+ mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+ mig->mc_gstatus = status;
+ mig->mc_domid = mig->mc_vcpuid = -1;
+ mig->mc_flags = flags;
+ cpu_nr = smp_processor_id();
+ /* Retrieve detector information */
+ x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+ &mig->mc_coreid, &mig->mc_core_threadid,
+ &mig->mc_apicid, NULL, NULL, NULL);
+
+ /* This is really meaningless */
+ if (v != NULL && ((d = v->domain) != NULL)) {
+ mig->mc_domid = d->domain_id;
+ mig->mc_vcpuid = v->vcpu_id;
+ } else {
+ mig->mc_domid = -1;
+ mig->mc_vcpuid = -1;
+ }
+
+ return 0;
+}
+
/* Utility function to perform MCA bank telemetry readout and to push that
* telemetry towards an interested dom0 for logging and diagnosis.
* The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum
mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
struct mca_summary *sp, cpu_banks_t* clear_bank)
{
- struct vcpu *v = current;
- struct domain *d;
- uint64_t gstatus, status, addr, misc;
- struct mcinfo_global mcg; /* on stack */
- struct mcinfo_common *mic;
- struct mcinfo_global *mig; /* on stack */
+ uint64_t gstatus, status;
+ struct mcinfo_global *mig = NULL; /* on stack */
mctelem_cookie_t mctc = NULL;
- uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+ uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
struct mc_info *mci = NULL;
mctelem_class_t which = MC_URGENT; /* XXXgcc */
- unsigned int cpu_nr;
int errcnt = 0;
int i;
enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
- cpu_nr = smp_processor_id();
- BUG_ON(cpu_nr != v->processor);
-
mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
- memset(&mcg, 0, sizeof (mcg));
- mcg.common.type = MC_TYPE_GLOBAL;
- mcg.common.size = sizeof (mcg);
- if (v != NULL && ((d = v->domain) != NULL)) {
- mcg.mc_domid = d->domain_id;
- mcg.mc_vcpuid = v->vcpu_id;
- } else {
- mcg.mc_domid = -1;
- mcg.mc_vcpuid = -1;
- }
- mcg.mc_gstatus = gstatus; /* MCG_STATUS */
-
switch (who) {
case MCA_MCE_HANDLER:
case MCA_MCE_SCAN:
- mcg.mc_flags = MC_FLAG_MCE;
+ mc_flags = MC_FLAG_MCE;
which = MC_URGENT;
break;
case MCA_POLLER:
case MCA_RESET:
- mcg.mc_flags = MC_FLAG_POLLED;
+ mc_flags = MC_FLAG_POLLED;
which = MC_NONURGENT;
break;
case MCA_CMCI_HANDLER:
- mcg.mc_flags = MC_FLAG_CMCI;
+ mc_flags = MC_FLAG_CMCI;
which = MC_NONURGENT;
break;
default:
BUG();
}
-
- /* Retrieve detector information */
- x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
- &mcg.mc_coreid, &mcg.mc_core_threadid,
- &mcg.mc_apicid, NULL, NULL, NULL);
/* If no mc_recovery_scan callback handler registered,
* this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum
recover = (mc_recoverable_scan)? 1: 0;
for (i = 0; i < 32 && i < nr_mce_banks; i++) {
- struct mcinfo_bank mcb; /* on stack */
+ struct mcinfo_bank *mib; /* on stack */
/* Skip bank if corresponding bit in bankmask is clear */
if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum
* a poller; this can fail (for example dom0 may not
* yet have consumed past telemetry). */
if (errcnt == 0) {
- if ((mctc = mctelem_reserve(which)) != NULL) {
+ if ( (mctc = mctelem_reserve(which)) != NULL ) {
mci = mctelem_dataptr(mctc);
mcinfo_clear(mci);
+ mig = (struct mcinfo_global*)x86_mcinfo_reserve
+ (mci, sizeof(struct mcinfo_global));
+ /* mc_info should at least hold up the global information */
+ ASSERT(mig);
+ mca_init_global(mc_flags, mig);
}
}
-
- memset(&mcb, 0, sizeof (mcb));
- mcb.common.type = MC_TYPE_BANK;
- mcb.common.size = sizeof (mcb);
- mcb.mc_bank = i;
- mcb.mc_status = status;
/* form a mask of which banks have logged uncorrected errors */
if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum
*/
recover = mc_recoverable_scan(status);
- addr = misc = 0;
-
- if (status & MCi_STATUS_ADDRV) {
- mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
- if (mfn_valid(paddr_to_pfn(addr))) {
- d = maddr_get_owner(addr);
- if (d != NULL && (who == MCA_POLLER ||
- who == MCA_CMCI_HANDLER))
- mcb.mc_domid = d->domain_id;
- }
- }
-
- if (status & MCi_STATUS_MISCV)
- mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
- mcb.mc_addr = addr;
- mcb.mc_misc = misc;
-
- if (who == MCA_CMCI_HANDLER) {
- mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
- rdtscll(mcb.mc_tsc);
- }
-
- /* Increment the error count; if this is the first bank
- * with a valid error then add the global info to the mcinfo. */
- if (errcnt++ == 0 && mci != NULL)
- x86_mcinfo_add(mci, &mcg);
-
- /* Add the bank data */
- if (mci != NULL)
- x86_mcinfo_add(mci, &mcb);
+ mib = mca_init_bank(who, mci, i);
if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum
wmb();
}
- if (mci != NULL && errcnt > 0) {
- x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
- mig = container_of(mic, struct mcinfo_global, common);
- if (mic == NULL)
- ;
- else if (pcc)
+ if (mig && errcnt > 0) {
+ if (pcc)
mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
else if (uc)
mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info
x86_mcinfo_nentries(mi) = 0;
}
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
{
int i;
unsigned long end1, end2;
- struct mcinfo_common *mic, *mic_base, *mic_index;
-
- mic = (struct mcinfo_common *)mcinfo;
+ struct mcinfo_common *mic_base, *mic_index;
+
mic_index = mic_base = x86_mcinfo_first(mi);
/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
/* check if there is enough size */
end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
- end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+ end2 = (unsigned long)((uint8_t *)mic_index + size);
if (end1 < end2)
- return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+ {
+ mce_printk(MCE_CRITICAL,
+ "mcinfo_add: No space left in mc_info\n");
+ return NULL;
+ }
/* there's enough space. add entry. */
- memcpy(mic_index, mic, mic->size);
x86_mcinfo_nentries(mi)++;
- return 0;
+ return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+ struct mcinfo_common *mic, *buf;
+
+ mic = (struct mcinfo_common *)mcinfo;
+ buf = x86_mcinfo_reserve(mi, mic->size);
+
+ if ( !buf )
+ mce_printk(MCE_CRITICAL,
+ "mcinfo_add: No space left in mc_info\n");
+ else
+ memcpy(buf, mic, mic->size);
+
+ return buf;
}
/* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
(struct mc_info *, uint16_t, uint64_t);
extern void x86_mce_callback_register(x86_mce_callback_t);
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
void x86_mcinfo_dump(struct mc_info *mi);
int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
#define MCINFO_HYPERCALLSIZE 1024
#define MCINFO_MAXSIZE 768
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
struct mc_info {
/* Number of mcinfo_* entries in mi_data */
uint32_t mi_nentries;
- uint32_t _pad0;
+ uint32_t flags;
uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
};
typedef struct mc_info mc_info_t;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2009-10-09 21:47 Eads, Joshua Michael (S&T-Student)
0 siblings, 0 replies; 170+ messages in thread
From: Eads, Joshua Michael (S&T-Student) @ 2009-10-09 21:47 UTC (permalink / raw)
To: xen-devel
I have an HVM guest and I am trying to have a usermode program in Dom0 query the context (CPU registers, specifically) of the guest.
I first tried using xc_domain_getcontext() in xenctrl.h but I haven't figured out what data structure ctxt_buf is that it returns. Next, I have tried using xc_vcpu_getcontext() in xenctrl.h but so far it always returns -1 for failure. For xc_vcpu_getcontext, I am passing in a vcpu number of 1 (I only have a single virtual CPU domU running) along with an unallocated vcpu_guest_context_t pointer.
Is this the right direction to pull guest registers, or is there another method I need to use to get the HVM guest context?
Thanks,
Josh
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2009-01-23 6:45 Alexia Benington
0 siblings, 0 replies; 170+ messages in thread
From: Alexia Benington @ 2009-01-23 6:45 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4183 bytes --]
Hi all,
My Dom0 crashed if I use the first grub configuration, but is ok if I use
the following one.
kernel /boot/xen-3.4-unstable.gz
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro
kernel /boot/xen-3.4-unstable.gz com1=9600,8n1 console=com1 iommu=1
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro xencons=ttyS
console=tty0 console=ttyS0
I've attached the full boot trace. Below is a snippet of the crash region.
Does anyone have any idea what's going on?
Thanks and have a nice day.
- Alexia
================================================
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6
iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN) root_entry = ffff83013bdea000
(XEN) root_entry[0] = 1374a0001
(XEN) context = ffff8301374a0000
(XEN) context[d0] = 101_13bde6001
(XEN) l3 = ffff83013bde6000
(XEN) l3_index = 2
(XEN) l3[2] = 137a83003
(XEN) l2 = ffff830137a83000
(XEN) l2_index = 1fb
(XEN) l2[1fb] = 137887003
(XEN) l1 = ffff830137887000
(XEN) l1_index = 1ed
(XEN) l1[1ed] = 0
(XEN) l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP:
[<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>] [<ffffffff88019be9>]
:usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50 EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS: 00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task
ffff8800eec867a0)
Stack: ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
[<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
[<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
[<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
[<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
[<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
[<ffffffff802f4e48>] pci_match_device+0x13/0xbd
[<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
[<ffffffff802f4f06>] pci_bus_match+0x14/0x20
[<ffffffff80346048>] driver_probe_device+0x52/0xa8
[<ffffffff80346177>] __driver_attach+0x6d/0xaa
[<ffffffff8034610a>] __driver_attach+0x0/0xaa
[<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
[<ffffffff803456a7>] bus_add_driver+0x7e/0x130
[<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
[<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
[<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
[<ffffffff8020a518>] system_call+0x68/0x6d
[<ffffffff8020a4b0>] system_call+0x0/0x6d
Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55
RIP [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
Killed
[-- Attachment #1.2: Type: text/html, Size: 5276 bytes --]
[-- Attachment #2: boottrace.txt --]
[-- Type: text/plain, Size: 16160 bytes --]
\ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.4-unstable (xxx@xxx.xxx.xxx) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) Thu Jan 22 12:06:54 EST 2009
(XEN) Latest ChangeSet: Thu Jan 22 11:07:32 2009 +0000 19067:a92ed09b4032
(XEN) Command line: com1=9600,8n1 console=com1 iommu=1
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009e800 (usable)
(XEN) 000000000009e800 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bfae1000 (usable)
(XEN) 00000000bfae1000 - 00000000bfb24000 (ACPI NVS)
(XEN) 00000000bfb24000 - 00000000bfd42000 (reserved)
(XEN) 00000000bfd42000 - 00000000bfd43000 (ACPI NVS)
(XEN) 00000000bfd43000 - 00000000bfd48000 (reserved)
(XEN) 00000000bfd48000 - 00000000bfd50000 (ACPI data)
(XEN) 00000000bfd50000 - 00000000bfd6b000 (ACPI NVS)
(XEN) 00000000bfd6b000 - 00000000bfd8a000 (reserved)
(XEN) 00000000bfd8a000 - 00000000bfd90000 (ACPI NVS)
(XEN) 00000000bfd90000 - 00000000bff00000 (usable)
(XEN) 00000000fed1c000 - 00000000fed20000 (reserved)
(XEN) 00000000ff000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 000000013c000000 (usable)
(XEN) System RAM: 4027MB (4124604kB)
(XEN) ACPI: RSDP 000F03C0, 0024 (r2 INTEL)
(XEN) ACPI: XSDT BFD4EE18, 005C (r1 INTEL DQ45CB 43 MSFT 10013)
(XEN) ACPI: FACP BFD4DD98, 00F4 (r4 INTEL A M I 6222004 MSFT 10013)
(XEN) ACPI: DSDT BFD48018, 4EFD (r1 INTEL DQ45CB 43 INTL 20051117)
(XEN) ACPI: FACS BFD56F40, 0040
(XEN) ACPI: APIC BFD4DF18, 006C (r2 INTEL DQ45CB 43 MSFT 10013)
(XEN) ACPI: MCFG BFD58E18, 003C (r1 INTEL DQ45CB 43 MSFT 97)
(XEN) ACPI: ASF! BFD57D18, 00A0 (r32 INTEL DQ45CB 43 TFSM F4240)
(XEN) ACPI: SPCR BFD58D18, 0050 (r1 INTEL DQ45CB 43 AMI. 3)
(XEN) ACPI: TCPA BFD58C98, 0032 (r2 INTEL DQ45CB 43 MSFT 1000013)
(XEN) ACPI: DMAR BFD42F18, 00D8 (r1 INTEL DQ45CB 43 INTL 1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2499.770 MHz processor.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping 07
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping 07
(XEN) Booting processor 2/2 eip 8c000
(XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping 07
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 4 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) mtrr: your CPUs had inconsistent fixed MTRR settings
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805bf88c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000134000000->0000000136000000 (970253 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff805bf88c
(XEN) Init. ramdisk: ffffffff805c0000->ffffffff80956400
(XEN) Phys-Mach map: ffffffff80957000->ffffffff810ce068
(XEN) Start info: ffffffff810cf000->ffffffff810cf4b4
(XEN) Page tables: ffffffff810d0000->ffffffff810dd000
(XEN) Boot stack: ffffffff810dd000->ffffffff810de000
(XEN) TOTAL: ffffffff80000000->ffffffff81400000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 108kB init memory.
kernel direct mapping tables up to ef60d000 @ 10e0000-1861000
Bootdata ok (command line is root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0)
Linux version 2.6.18.8-xen (root@amber) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Jan 22 12:02:23 EST 2009
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 00000000ef60d000 (usable)
DMI 2.4 present.
No mptable found.
>>> ERROR: Invalid checksum
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to xen
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c0000000 (gap: bff00000:3ee1c000)
Built 1 zonelists. Total pages: 967088
Kernel command line: root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Xen reported: 2499.770 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled:
Aperture: 64 megabytes
Kernel range: ffff880005a7a000 - ffff880009a7a000
Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3764092k/3921972k available (2027k kernel code, 149244k reserved, 887k data, 180k init)
Calibrating delay using timer specific routine.. 5000.60 BogoMIPS (lpj=25003009)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
migration_cost=9
checking if image is initramfs... it is
Freeing initrd memory: 3673k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=000109f1
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 10 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:02: ioport range 0xa20-0xa3f has been reserved
pnp: 00:02: ioport range 0xa00-0xa1f has been reserved
pnp: 00:02: ioport range 0xb78-0xb7f has been reserved
pnp: 00:02: ioport range 0xf78-0xf7f has been reserved
pnp: 00:09: ioport range 0x400-0x47f could not be reserved
pnp: 00:09: ioport range 0x1180-0x119f has been reserved
pnp: 00:09: ioport range 0x500-0x57f has been reserved
PCI: Bridge: 0000:00:01.0
IO window: d000-dfff
MEM window: c0000000-d00fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: d0100000-d01fffff
PREFETCH window: disabled.
GSI 16 sharing vector 0xA8 and IRQ 16
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1232672414.325:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 180k freed
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ AMI] OemTableId [ IST] [20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
ACPI: CPU2 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
ACPI: CPU3 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6 iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN) root_entry = ffff83013bdea000
(XEN) root_entry[0] = 1374a0001
(XEN) context = ffff8301374a0000
(XEN) context[d0] = 101_13bde6001
(XEN) l3 = ffff83013bde6000
(XEN) l3_index = 2
(XEN) l3[2] = 137a83003
(XEN) l2 = ffff830137a83000
(XEN) l2_index = 1fb
(XEN) l2[1fb] = 137887003
(XEN) l1 = ffff830137887000
(XEN) l1_index = 1ed
(XEN) l1[1ed] = 0
(XEN) l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP:
[<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>] [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50 EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS: 00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task ffff8800eec867a0)
Stack: ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
[<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
[<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
[<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
[<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
[<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
[<ffffffff802f4e48>] pci_match_device+0x13/0xbd
[<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
[<ffffffff802f4f06>] pci_bus_match+0x14/0x20
[<ffffffff80346048>] driver_probe_device+0x52/0xa8
[<ffffffff80346177>] __driver_attach+0x6d/0xaa
[<ffffffff8034610a>] __driver_attach+0x0/0xaa
[<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
[<ffffffff803456a7>] bus_add_driver+0x7e/0x130
[<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
[<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
[<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
[<ffffffff8020a518>] system_call+0x68/0x6d
[<ffffffff8020a4b0>] system_call+0x0/0x6d
Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55
RIP [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
Killed
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2008-11-19 22:29 Bowen, Clair
2008-11-19 22:36 ` James Harper
0 siblings, 1 reply; 170+ messages in thread
From: Bowen, Clair @ 2008-11-19 22:29 UTC (permalink / raw)
To: Xen-devel@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 126 bytes --]
Does anybody know if Storport is supported on XEN? I only see references to SCSIPORT (i.e xenscsi.sys).
Regards,
CJ
[-- Attachment #1.2: Type: text/html, Size: 4277 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
2008-11-19 22:29 Bowen, Clair
@ 2008-11-19 22:36 ` James Harper
0 siblings, 0 replies; 170+ messages in thread
From: James Harper @ 2008-11-19 22:36 UTC (permalink / raw)
To: Bowen, Clair, Xen-devel
>
> Does anybody know if Storport is supported on XEN? I only see
references
> to SCSIPORT (i.e xenscsi.sys).
>
If you are referring to the gplpv drivers, then I have only developed
with scsiport at the moment. Storport is only supported under 2003 and
later and I didn't want to maintain two versions of the same code. I'm
not yet convinced that storport will give any noticeable advantage over
scsiport for what we are doing.
xenvbd (scsi emulation of block device) and xenscsi (pvscsi scsi
passthrough) are both scsiport drivers, but xenscsi doesn't work at the
moment as it only worked with a slightly modified version of the 3.2
version of pvscsi. It will be incompatible with the 3.3 version. I will
update it once I get 3.3 installed on my dev box (waiting for some
Debian packages).
Thanks
James
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2008-10-10 12:27 Swapna Shingre
0 siblings, 0 replies; 170+ messages in thread
From: Swapna Shingre @ 2008-10-10 12:27 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 167 bytes --]
hi all,
can anyone tell me what exactly the iret hypercall does?
and, is there any way to disable the fast system call handlers and use
normal system call handling?
[-- Attachment #1.2: Type: text/html, Size: 204 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2008-09-18 7:10 James Song
0 siblings, 0 replies; 170+ messages in thread
From: James Song @ 2008-09-18 7:10 UTC (permalink / raw)
To: xen-devel
I test stubdom in xen-3.3.1, when I start it, just see the message bellow using "xm li" . It seems stubdom haven't start.
Name ID Mem VCPUs State Time(s)
Domain-0 0 964 2 r----- 34.8
hvmachine 1 1024 1 ------ 0.0
the two config files :
#hvmachine
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 256
name = "hvmachine"
vcpus=2
vif = [ 'type=ioemu, bridge=eth0' ]
device_model = '/usr/lib/xen/bin/stubdom-dm'
boot="cd"
sdl=0
opengl=0
vnc=1
vnclisten="172.30.206.1"
stdvga=0
-------------------------------------------------------------------------
#hvmachine-dm
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
vif = [ 'ip=172.30.206.1', 'bridge=eth0,mac=00:16:3e:21:a2:94' ]
disk = [ 'file:/home/images/opensuse11-2/disk0,hda,w' ]
what's wrong I make?
best regards,
-- James
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
2007-06-11 10:53 ` pradeep singh rautela
0 siblings, 1 reply; 170+ messages in thread
From: Gautham Kampalapur Shankar, TLS, Chennai @ 2007-06-11 10:35 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/html, Size: 420 bytes --]
[-- Attachment #2: Type: text/plain, Size: 984 bytes --]
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
@ 2007-06-11 10:53 ` pradeep singh rautela
0 siblings, 0 replies; 170+ messages in thread
From: pradeep singh rautela @ 2007-06-11 10:53 UTC (permalink / raw)
To: Gautham Kampalapur Shankar, TLS, Chennai; +Cc: xen-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/11/07, Gautham Kampalapur Shankar, TLS, Chennai wrote:
>
>
>
>
> How xen bus and xen store works ? How they related to each other ?
Gautham you are supposed to use a proper subject for a prompt reply.
thanks
- --
- ---
pradeep singh rautela
"Genius is 1% inspiration, and 99% perspiration" - not me :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iD8DBQFGbSmLky6Gd9lpXlERAu12AJ4kdzmyofihA5fmShaCuNbQv5z+ZQCePElh
JA4gh+llY+9GVInFabWvVHw=
=UC9B
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2006-10-09 11:55 Timo Benk
0 siblings, 0 replies; 170+ messages in thread
From: Timo Benk @ 2006-10-09 11:55 UTC (permalink / raw)
To: xen-devel
Hi,
i am using two domains, which are internally connected by one virtual interface.
xendom1: Backend Domain without a physical interface
xendom2: normal Domain-U using xendom1 as a vif-Backend-Domain
--------- ---------
| xendom1 | | xendom2 |
| | | |
| vif2.0--------eth0 |
| | | |
--------- ---------
Then i add another virtual interface to xendom2.
--------- ---------
| xendom1 | | xendom2 |
| | | |
| vif2.0--------eth0 |
| | | |
| vif2.1--------eth1 |
| | | |
--------- ---------
Domain-0:~ # xm network-attach xendom2 backend=xendom1
script=vif-nothing
---<snip>---
# /etc/xen/script/vif-nothing in Domain xendom1
dir=$(dirname "$0")
. "$dir/vif-common.sh"
success
---<snap>---
Then i save both domains:
Domain-0:~ # xm save xendom2
Domain-0:~ # xm save xendom1
Error: /usr/lib/xen/bin/xc_save 17 4 0 0 0 failed
Usage: xm save <Domain> <CheckpointFile>
Save a domain state to restore later.
Domain-0:~ # xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 985 2 r----- 62.5
Zombie-migrating-xendom2 5 512 1 ---s-d 18.0
xendom1 4 128 1 ---s-- 19.6
Both domains are not reachable anymore, i need to destroy xendom1 and xendom2 lives another life as a zombie domain :-(
Greetings,
-timo
--
Timo Benk - B1 Systems GmbH (http://www.b1-systems.de)
Jabber ID: fry@jabber.org - ICQ ID: #241877854
PGP Public Key: http://m28s01.vlinux.de/b1_gpg_key.asc
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2006-07-17 14:44 Li, Xin B
0 siblings, 0 replies; 170+ messages in thread
From: Li, Xin B @ 2006-07-17 14:44 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
on x86_64, when guest has more than 2G memory, "startx" will cause qemu
dm die, this patch fixes it.
Signed-off-by: Xin Li <xin.b.li@intel.com>
diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
static void vga_draw_graphic(VGAState *s, int full_update)
{
int y1, y, update, page_min, page_max, linesize, y_start,
double_scan, mask;
- int width, height, shift_control, line_offset, page0, page1,
bwidth;
+ int width, height, shift_control, line_offset, bwidth;
+ ram_addr_t page0, page1;
int disp_width, multi_scan, multi_run;
uint8_t *d;
uint32_t v, addr1, addr;
[-- Attachment #2: vga.patch --]
[-- Type: application/octet-stream, Size: 621 bytes --]
diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
static void vga_draw_graphic(VGAState *s, int full_update)
{
int y1, y, update, page_min, page_max, linesize, y_start, double_scan, mask;
- int width, height, shift_control, line_offset, page0, page1, bwidth;
+ int width, height, shift_control, line_offset, bwidth;
+ ram_addr_t page0, page1;
int disp_width, multi_scan, multi_run;
uint8_t *d;
uint32_t v, addr1, addr;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2006-06-07 23:48 vineet chadha
0 siblings, 0 replies; 170+ messages in thread
From: vineet chadha @ 2006-06-07 23:48 UTC (permalink / raw)
To: xen-devel, xen-users
Hi,
Compiling xen-3.0.2.2 on host redhat 2.4.18 kernel I am getting following error:
make[2]: Entering directory `/root/software/xen-3.0.2-2'
if grep "^CONFIG_MODULES=" linux-2.6.16-xen/.config ; then \
make -C linux-2.6.16-xen ARCH=i386 modules ; \
make -C linux-2.6.16-xen ARCH=i386
INSTALL_MOD_PATH=/root/software/xen-3.0.2-2/dist/install
modules_install ; \
fi
CONFIG_MODULES=y
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
CHK include/linux/version.h
Building modules, stage 2.
MODPOST
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt
rm: invalid option -- x
Try `rm --help' for more information.
make[3]: *** [_modinst_] Error 1
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/root/software/xen-3.0.2-2'
make[1]: *** [linux-2.6-xen-install] Error 2
make[1]: Leaving directory `/root/software/xen-3.0.2-2'
make: *** [install-kernels] Error 1
Please help
-John
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2006-06-02 13:23 Kevin Tronkowski
0 siblings, 0 replies; 170+ messages in thread
From: Kevin Tronkowski @ 2006-06-02 13:23 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
Attached is a patch which extends vmxassist to handle two cases
related to mode switching found while experimenting with different
boot loaders.
The first case is use of the JMP instruction with memory location
operands to complete a switch to protected mode. This patch adds
emulation for this form of the JMP instruction to vmxassist.
The second case is where boot loader code does not save/restore a
non-zero SS register across a protected mode traversal.
Zeroing the SS register in vmxassist results in all sorts of problems
in the domU after returning back to real mode. This patch stores
segment register values before entering protected mode and correctly
restores the old values (instead of an incorrect zero value) when
reentering real mode.
Signed-off-by Kevin Tronkowski <ktronkowski@virtualiron.com>
Kevin
[-- Attachment #2: vm86.patch --]
[-- Type: application/octet-stream, Size: 4282 bytes --]
diff -r 6993a0f91efc tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c Thu Jun 1 18:10:00 2006 +0100
+++ b/tools/firmware/vmxassist/vm86.c Thu Jun 1 16:40:28 2006 -0400
@@ -36,6 +36,8 @@
static unsigned prev_eip = 0;
enum vm86_mode mode = 0;
+
+static struct regs saved_rm_regs;
#ifdef DEBUG
int traceset = 0;
@@ -795,6 +797,8 @@ protected_mode(struct regs *regs)
oldctx.esp = regs->uesp;
oldctx.eflags = regs->eflags;
+ memset(&saved_rm_regs, 0, sizeof(struct regs));
+
/* reload all segment registers */
if (!load_seg(regs->cs, &oldctx.cs_base,
&oldctx.cs_limit, &oldctx.cs_arbytes))
@@ -808,6 +812,7 @@ protected_mode(struct regs *regs)
load_seg(0, &oldctx.es_base,
&oldctx.es_limit, &oldctx.es_arbytes);
oldctx.es_sel = 0;
+ saved_rm_regs.ves = regs->ves;
}
if (load_seg(regs->uss, &oldctx.ss_base,
@@ -817,6 +822,7 @@ protected_mode(struct regs *regs)
load_seg(0, &oldctx.ss_base,
&oldctx.ss_limit, &oldctx.ss_arbytes);
oldctx.ss_sel = 0;
+ saved_rm_regs.uss = regs->uss;
}
if (load_seg(regs->vds, &oldctx.ds_base,
@@ -826,6 +832,7 @@ protected_mode(struct regs *regs)
load_seg(0, &oldctx.ds_base,
&oldctx.ds_limit, &oldctx.ds_arbytes);
oldctx.ds_sel = 0;
+ saved_rm_regs.vds = regs->vds;
}
if (load_seg(regs->vfs, &oldctx.fs_base,
@@ -835,6 +842,7 @@ protected_mode(struct regs *regs)
load_seg(0, &oldctx.fs_base,
&oldctx.fs_limit, &oldctx.fs_arbytes);
oldctx.fs_sel = 0;
+ saved_rm_regs.vfs = regs->vfs;
}
if (load_seg(regs->vgs, &oldctx.gs_base,
@@ -844,6 +852,7 @@ protected_mode(struct regs *regs)
load_seg(0, &oldctx.gs_base,
&oldctx.gs_limit, &oldctx.gs_arbytes);
oldctx.gs_sel = 0;
+ saved_rm_regs.vgs = regs->vgs;
}
/* initialize jump environment to warp back to protected mode */
@@ -880,16 +889,22 @@ real_mode(struct regs *regs)
if (regs->uss >= HIGHMEM)
panic("%%ss 0x%lx higher than 1MB", regs->uss);
regs->uss = address(regs, regs->uss, 0) >> 4;
+ } else {
+ regs->uss = saved_rm_regs.uss;
}
if (regs->vds != 0) {
if (regs->vds >= HIGHMEM)
panic("%%ds 0x%lx higher than 1MB", regs->vds);
regs->vds = address(regs, regs->vds, 0) >> 4;
+ } else {
+ regs->vds = saved_rm_regs.vds;
}
if (regs->ves != 0) {
if (regs->ves >= HIGHMEM)
panic("%%es 0x%lx higher than 1MB", regs->ves);
regs->ves = address(regs, regs->ves, 0) >> 4;
+ } else {
+ regs->ves = saved_rm_regs.ves;
}
/* this should get us into 16-bit mode */
@@ -971,6 +986,39 @@ jmpl(struct regs *regs, int prefix)
} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
eip = (prefix & DATA32) ? fetch32(regs) : fetch16(regs);
cs = fetch16(regs);
+
+ TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+ regs->cs = cs;
+ regs->eip = eip;
+ set_mode(regs, VM86_REAL);
+ } else
+ panic("jmpl");
+}
+
+static void
+jmpl_indirect(struct regs *regs, int prefix, unsigned modrm)
+{
+ unsigned n = regs->eip;
+ unsigned cs, eip;
+ unsigned addr;
+
+ addr = operand(prefix, regs, modrm);
+
+ if (mode == VM86_REAL_TO_PROTECTED) { /* jump to protected mode */
+ eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+ addr += (prefix & DATA32) ? 4 : 2;
+ cs = read16(addr);
+
+ TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+ regs->cs = cs;
+ regs->eip = eip;
+ set_mode(regs, VM86_PROTECTED);
+ } else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
+ eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+ addr += (prefix & DATA32) ? 4 : 2;
+ cs = read16(addr);
TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
@@ -1306,6 +1354,23 @@ opcode(struct regs *regs)
}
goto invalid;
+ case 0xFF: /* jmpl (indirect) */
+ if ((mode == VM86_REAL_TO_PROTECTED) ||
+ (mode == VM86_PROTECTED_TO_REAL)) {
+ unsigned modrm = fetch8(regs);
+
+ switch((modrm >> 3) & 7) {
+ case 5:
+ jmpl_indirect(regs, prefix, modrm);
+ return OPC_INVALID;
+
+ default:
+ break;
+ }
+
+ }
+ goto invalid;
+
case 0xEB: /* short jump */
if ((mode == VM86_REAL_TO_PROTECTED) ||
(mode == VM86_PROTECTED_TO_REAL)) {
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2006-04-06 22:26 Nivedita Singhvi
0 siblings, 0 replies; 170+ messages in thread
From: Nivedita Singhvi @ 2006-04-06 22:26 UTC (permalink / raw)
To: xen-devel, openib-general; +Cc: Jiuxing Liu
[-- Attachment #1.1: Type: text/plain, Size: 913 bytes --]
Hello!
Just wanted to let everyone know Jiuxing has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:
http://xenbits.xensource.com/ext/xen-smartio.hg
This contains the current source code for a xen infiniband frontend
and backend driver. The source code is in very preliminary stages
of development, just a proof of concept for now (works). We have
a long way to go. We'd like to invite interested folks to take a look
and get involved in the continuing design and development as an
open-source community.
We will be putting up a Wiki page for this shortly on the Xen Wiki.
Stay tuned...
There is also a mailing list we set up for discussion on
virtualization of smart I/O in Xen at:
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-smartio
However, at Ian's request we're going to contain most discussion
to xen-devel itself.
thanks,
Nivedita
[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2006-02-10 8:55 Li, Xin B
0 siblings, 0 replies; 170+ messages in thread
From: Li, Xin B @ 2006-02-10 8:55 UTC (permalink / raw)
To: leendert; +Cc: xen-devel
Leendert, when I'm reading the vmxassist code, I think we need this
patch, can you take a look for me?
Thanks
-Xin
diff -r 47013962e411 tools/firmware/vmxassist/setup.c
--- a/tools/firmware/vmxassist/setup.c Fri Feb 10 02:23:36 2006
+++ b/tools/firmware/vmxassist/setup.c Fri Feb 10 15:28:17 2006
@@ -363,7 +363,7 @@
initialize_real_mode = 1;
cr0 = get_cr0();
-#ifndef TEST
+#ifdef TEST
set_cr0(cr0 | CR0_PE);
#endif
set_cr0(cr0 & ~CR0_PE);
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2005-11-19 22:44 Purav Saraiya
0 siblings, 0 replies; 170+ messages in thread
From: Purav Saraiya @ 2005-11-19 22:44 UTC (permalink / raw)
To: xen-devel
I am facing problems with debugging DomU.
I have made changes in the gdt table in the file head.S for Dom U. Because
of that the domain is crashing.
For debugging, I followed the steps mentioned in the file
/xen-unstable/tools/debugger/gdb/README. I also made changes in the
/xen/Rules.mk file and compiled domU with -g C flag.
However, as mentioned in the README file no
/var/xen/dump/<Domain-name>.<DomainID>.core file is generated.
Rules.mk file :
verbose ?= y
debug ?= y
perfc ?= n
perfc_arrays?= n
domu_debug ?= y
crash_debug ?= y
Am I missing something?
Thanks for replies.
-Purav
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-10-02 2:59 Prashanth Radhakrishnan
0 siblings, 0 replies; 170+ messages in thread
From: Prashanth Radhakrishnan @ 2005-10-02 2:59 UTC (permalink / raw)
To: mvrable; +Cc: xen-devel
> Yes, I'm still working on it. The focus of that work was copy-on-write
> sharing of memory for the purposes of building a (virtual) network of
> honeypot systems. We have a paper in SOSP this year, talking about that
> work and the copy-on-write memory implementation. See
> http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin.pdf
> for some information.
>
> I'm presently working on updating and cleaning that work up.
>
> --Michael Vrable
Thanks for the info, Michael. Just wondering if this code has been checked
into the Xen-unstable branch, or around when it would be checked in.
(I din't find any related checkin by searching at
http://lists.xensource.com/archives/html/xen-changelog/)
thanks again,
prashanth
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-09-29 5:55 Li, Chengyuan
0 siblings, 0 replies; 170+ messages in thread
From: Li, Chengyuan @ 2005-09-29 5:55 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
Set guest selectors to be null if it's not valid when switch to
protected-mode in the guest firmware.
Signed-off-by: Chengyuan Li <chengyuan.li@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>
Thanks,
Chengyuan
[-- Attachment #2: vmxassist_selector.patch --]
[-- Type: application/octet-stream, Size: 2097 bytes --]
diff -r f069a06e650f tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c Wed Sep 28 21:18:30 2005
+++ b/tools/firmware/vmxassist/vm86.c Thu Sep 29 12:59:36 2005
@@ -470,10 +470,21 @@
unsigned long long entry;
/* protected mode: use seg as index into gdt */
- if (sel == 0 || sel > oldctx.gdtr_limit)
+ if (sel > oldctx.gdtr_limit)
return 0;
+ if (sel == 0) {
+ arbytes->fields.null_bit = 1;
+ return 1;
+ }
+
entry = ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];
+
+ /* Check the P bit fisrt*/
+ if (!((entry >> (15+32)) & 0x1) && sel != 0) {
+ return 0;
+ }
+
*base = (((entry >> (56-24)) & 0xFF000000) |
((entry >> (32-16)) & 0x00FF0000) |
((entry >> ( 16)) & 0x0000FFFF));
@@ -519,22 +530,42 @@
if (load_seg(regs->ves, &oldctx.es_base,
&oldctx.es_limit, &oldctx.es_arbytes))
oldctx.es_sel = regs->ves;
+ else {
+ load_seg(0, &oldctx.es_base,&oldctx.es_limit, &oldctx.es_arbytes);
+ oldctx.es_sel = 0;
+ }
if (load_seg(regs->uss, &oldctx.ss_base,
&oldctx.ss_limit, &oldctx.ss_arbytes))
oldctx.ss_sel = regs->uss;
+ else {
+ load_seg(0, &oldctx.ss_base, &oldctx.ss_limit, &oldctx.ss_arbytes);
+ oldctx.ss_sel = 0;
+ }
if (load_seg(regs->vds, &oldctx.ds_base,
&oldctx.ds_limit, &oldctx.ds_arbytes))
oldctx.ds_sel = regs->vds;
+ else {
+ load_seg(0, &oldctx.ds_base, &oldctx.ds_limit, &oldctx.ds_arbytes);
+ oldctx.ds_sel = 0;
+ }
if (load_seg(regs->vfs, &oldctx.fs_base,
&oldctx.fs_limit, &oldctx.fs_arbytes))
oldctx.fs_sel = regs->vfs;
+ else {
+ load_seg(0, &oldctx.fs_base, &oldctx.fs_limit, &oldctx.fs_arbytes);
+ oldctx.fs_sel = 0;
+ }
if (load_seg(regs->vgs, &oldctx.gs_base,
&oldctx.gs_limit, &oldctx.gs_arbytes))
oldctx.gs_sel = regs->vgs;
+ else {
+ load_seg(0, &oldctx.gs_base, &oldctx.gs_limit, &oldctx.gs_arbytes);
+ oldctx.gs_sel = 0;
+ }
/* initialize jump environment to warp back to protected mode */
regs->cs = CODE_SELECTOR;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* RE: (no subject)
@ 2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-24 0:28 ` Christian Limpach
0 siblings, 1 reply; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-23 19:07 UTC (permalink / raw)
To: Christian Limpach; +Cc: xen-devel
> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins)
> Sent: Wednesday, September 21, 2005 2:50 PM
> To: 'Christian Limpach'
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] (no subject)
>
> > > I suppose it would be nice if on ia64 just 'make' did the
> > > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > > specify it on the command line. In that case, adding it
> > > to all the calls to mkbuildtree is necessary. How do
> > > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > > if x86 (or x86_64) and the architecture it is running on
> > > (e.g. ia64) otherwise?
> >
> > I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> > dependent on ARCH, like you did in your original patch...
>
> Thanks very much! I tried it and it works great! Using
> this, I have started committing files into the ia64 subdirs
> of -sparse in xen-ia64-unstable.hg which will be pulled
> into the xen-unstable tree at the next sync. I have already
> built and tested a "driver-less" domain0 from -sparse.
Oops, I tried it only using a cross-compiler. When I compiled
natively on ia64, it is still necessary to specify
LINUX_ARCH=ia64 on the make-line, else I get x86 configs.
I think the fix is to change in buildconfig/Rules.mk from
ifneq ($(ARCH),ia64)
to
ifneq ($(XEN_TARGET_ARCH),ia64)
I'll roll this fix in at the next merge with xen-ia64-unstable.
Thanks,
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-24 0:28 ` Christian Limpach
0 siblings, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-24 0:28 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On 9/23/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> Oops, I tried it only using a cross-compiler. When I compiled
> natively on ia64, it is still necessary to specify
> LINUX_ARCH=ia64 on the make-line, else I get x86 configs.
>
> I think the fix is to change in buildconfig/Rules.mk from
>
> ifneq ($(ARCH),ia64)
> to
> ifneq ($(XEN_TARGET_ARCH),ia64)
>
> I'll roll this fix in at the next merge with xen-ia64-unstable.
Yes, thanks!
christian
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-21 20:49 Magenheimer, Dan (HP Labs Fort Collins)
0 siblings, 0 replies; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-21 20:49 UTC (permalink / raw)
To: Christian Limpach; +Cc: xen-devel
> > I suppose it would be nice if on ia64 just 'make' did the
> > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > specify it on the command line. In that case, adding it
> > to all the calls to mkbuildtree is necessary. How do
> > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > if x86 (or x86_64) and the architecture it is running on
> > (e.g. ia64) otherwise?
>
> I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> dependent on ARCH, like you did in your original patch...
Thanks very much! I tried it and it works great! Using
this, I have started committing files into the ia64 subdirs
of -sparse in xen-ia64-unstable.hg which will be pulled
into the xen-unstable tree at the next sync. I have already
built and tested a "driver-less" domain0 from -sparse.
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 21:18 ` Christian Limpach
0 siblings, 1 reply; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 20:52 UTC (permalink / raw)
To: Christian Limpach; +Cc: xen-devel
> > > You have to export LINUX_ARCH to the script. We don't want to
> > > unconditionally polute the environment of all the commands we
> > > run, so you'll have to add it to all the calls to mkbuildtree.
> >
> > I'm not sure I follow... I don't know exactly how make or bash
> > work wrt to exporting... I didn't explicitly export LINUX_ARCH
> > but it seems to be known by mkbuildtree and all the mk.linux's
> > anyway. (I successfully built for x86 and ia64 with the
> > patch.)
> >
> > Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> > so as to avoid polluting the environment?
>
> Rules.mk is fine. What I meant is that LINUX_ARCH won't get
> passed to mkbuildtree unless you add it to its environment.
> I confirmed this now by adding this to mkbuildtree:
> echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> LINUX_ARCH is empty and thus your hook script won't run. Maybe
> you have LINUX_ARCH set in your shell environment where you ran
> make? Odd...
No, it's not in my shell environment. However, when I run make
to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
I'm guessing make must export it to subshells. If I add the
'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
do get run.
But if I build (for xen/x86) with just 'make', nothing gets
echoed to the file and, as you pointed out, no hook script
gets run. But that's the default behavior we want, correct?
I suppose it would be nice if on ia64 just 'make' did the
right thing, e.g. set LINUX_ARCH=ia64 without the need to
specify it on the command line. In that case, adding it
to all the calls to mkbuildtree is necessary. How do
I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
if x86 (or x86_64) and the architecture it is running on
(e.g. ia64) otherwise?
So I think the patch is OK as is... I've built successfully
for both x86 and ia64... but I can still change it and
resubmit if you prefer the other way.
Thanks,
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 21:18 ` Christian Limpach
0 siblings, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-19 21:18 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On Mon, Sep 19, 2005 at 01:52:36PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Rules.mk is fine. What I meant is that LINUX_ARCH won't get
> > passed to mkbuildtree unless you add it to its environment.
> > I confirmed this now by adding this to mkbuildtree:
> > echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> > LINUX_ARCH is empty and thus your hook script won't run. Maybe
> > you have LINUX_ARCH set in your shell environment where you ran
> > make? Odd...
>
> No, it's not in my shell environment. However, when I run make
> to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
> I'm guessing make must export it to subshells. If I add the
> 'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
> do get run.
Yes, that explains it.
> I suppose it would be nice if on ia64 just 'make' did the
> right thing, e.g. set LINUX_ARCH=ia64 without the need to
> specify it on the command line. In that case, adding it
> to all the calls to mkbuildtree is necessary. How do
> I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> if x86 (or x86_64) and the architecture it is running on
> (e.g. ia64) otherwise?
I'll check it in tomorrow, and I'll make it set LINUX_ARCH
dependent on ARCH, like you did in your original patch...
Thanks!
christian
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 19:58 ` Christian Limpach
0 siblings, 1 reply; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 19:20 UTC (permalink / raw)
To: Christian Limpach; +Cc: xen-devel
> > > Please define LINUX_ARCH in buildconfigs/Rules.mk and use
> that where
> > > we run make ARCH=xen.
> > > If you can name your config file xen0_defconfig_ia64 and use
> > > LINUX_ARCH for the path, then you won't need to duplicate
> the config
> > > file code.
> >
> > OK, I see. This cleans it up nicely. New patch attached.
>
> You have to export LINUX_ARCH to the script. We don't want to
> unconditionally polute the environment of all the commands we
> run, so you'll have to add it to all the calls to mkbuildtree.
I'm not sure I follow... I don't know exactly how make or bash
work wrt to exporting... I didn't explicitly export LINUX_ARCH
but it seems to be known by mkbuildtree and all the mk.linux's
anyway. (I successfully built for x86 and ia64 with the
patch.)
Or are you suggesting I *not* define it in buildconfigs/Rules.mk
so as to avoid polluting the environment?
> I think I'd prefer xen-mkbuildtree-{pre,post} as the name of
> the scripts
> to run, but not too fussed about that...
That's OK with me. If enlightenment (is that a bad word in
Xen land now?) from the above requires me to re-generate
the patch, I will change the names.
Thanks!
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 19:58 ` Christian Limpach
0 siblings, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-19 19:58 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On Mon, Sep 19, 2005 at 12:20:41PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > > OK, I see. This cleans it up nicely. New patch attached.
> >
> > You have to export LINUX_ARCH to the script. We don't want to
> > unconditionally polute the environment of all the commands we
> > run, so you'll have to add it to all the calls to mkbuildtree.
>
> I'm not sure I follow... I don't know exactly how make or bash
> work wrt to exporting... I didn't explicitly export LINUX_ARCH
> but it seems to be known by mkbuildtree and all the mk.linux's
> anyway. (I successfully built for x86 and ia64 with the
> patch.)
>
> Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> so as to avoid polluting the environment?
Rules.mk is fine. What I meant is that LINUX_ARCH won't get
passed to mkbuildtree unless you add it to its environment.
I confirmed this now by adding this to mkbuildtree:
echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
LINUX_ARCH is empty and thus your hook script won't run. Maybe
you have LINUX_ARCH set in your shell environment where you ran
make? Odd...
> That's OK with me. If enlightenment (is that a bad word in
> Xen land now?) from the above requires me to re-generate
> the patch, I will change the names.
Cheers!
christian
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-19 16:57 Magenheimer, Dan (HP Labs Fort Collins)
0 siblings, 0 replies; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 16:57 UTC (permalink / raw)
To: Christian.Limpach; +Cc: Jerone Young, xen-devel
> > > Why are you piping in tons of nothing into Make here
> using the "yes"
> > > command?
> >
> > This mechanically does the same as manually hitting
> > "enter" at every prompt from "make oldconfig", thus it
> > applies the default response for every unconfigured
> > option without manual intervention.
>
> I think it's preferable to have default config files which don't cause
> any prompting.
>
> Also if people upgrade, they probably want to be prompted on any new
> options. If not, then let's get the default behaviour for "make
> oldconfig" changed upstream...
I've just used this for convenience. The defconfigs in
Linux/ia64 cause prompting and the config change required for
Xen/ia64 support (because it is transparently paravirtualized)
is adding "CONFIG_XEN=y". But I can easily put the output
of make oldconfig in the xen defconfig file if the
preference is to have no prompting (thus the "yes" pipe
is removed from the previously posted patch).
Thanks,
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 17:39 ` Christian Limpach
0 siblings, 1 reply; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 16:49 UTC (permalink / raw)
To: xen-devel; +Cc: Christian.Limpach
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
(Sorry about the "no subject" in the original message...
fat fingers on my part.)
> Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> we run make ARCH=xen.
> If you can name your config file xen0_defconfig_ia64 and use
> LINUX_ARCH for the path, then you won't need to duplicate the config
> file code.
OK, I see. This cleans it up nicely. New patch attached.
> Please also change all mk.linux files.
Done.
> > 2) A sequence of mkbuildtree "massage" commands need to
> > be executed before mkbuildtree does its linking thing.
> > Perhaps this could be done as:
> > if -e mkbuildtree.prelink.$XENARCH
> > mkbuildtree.prelink.$XENARCH
> > Though ia64 doesn't need it, maybe also add a "postlink"
> > equivalent?
>
> Why do you need to move these out of the way in the first place? If
> any of the changes we've made break ia64, then we should cleanup our
> changes.
Do the changes have no impact to non-Xen non-x86 kernels?
Since xenlinux/ia64 is transparently paravirtualized,
the changes looked like they might be xen-specific, and
xenlinux/ia64 has been running out-of-tree without any
of those changes, the script moves them aside. If there's
no impact, I can move them back in (but will probably
do so slowly for testing purposes).
In any case, drivers/xen definitely is not yet fully
archdep, so I need to use the pre- or post-mkbuildtree
to do some patching in the short term. Agree in the longer
term, these files should be empty but if you don't mind
greatly, having the archdep hooks there will probably
make things easier for arch's for now.
> > Could someone with the necessary build knowledge make
> > the improvements and commit this please? Let me know if/when
> > it goes in and I will populate the ia64 -sparse branches.
>
> Please give creating a patch another try, taking the suggestions above
> into consideration. Thanks!
OK, let me know if this is better.
Thanks,
Dan
[-- Attachment #2: xenia64sparse2 --]
[-- Type: application/octet-stream, Size: 7395 bytes --]
diff -r ec01850d0ee9 buildconfigs/Rules.mk
--- a/buildconfigs/Rules.mk Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/Rules.mk Mon Sep 19 10:45:52 2005
@@ -14,6 +14,9 @@
# Setup pristine search path
PRISTINE_SRC_PATH ?= .:..
vpath pristine-% $(PRISTINE_SRC_PATH)
+
+# By default, build Linux with ARCH=xen (overridden by some non arch's)
+LINUX_ARCH ?= xen
# Expand Linux series to Linux version
LINUX_SERIES ?= 2.6
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.4-xenU
--- a/buildconfigs/mk.linux-2.4-xenU Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.4-xenU Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
# The real action starts here!
build: $(LINUX_DIR)/include/linux/autoconf.h
if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
fi
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
$(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
rm -rf $(LINUX_DIR)
@@ -36,16 +36,16 @@
( cd $(LINUX_DIR) ; \
sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
rm -f Makefile ; mv Mk.tmp Makefile )
- make -C $(LINUX_DIR) ARCH=xen oldconfig
- make -C $(LINUX_DIR) ARCH=xen dep
+ make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
+ make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
config: CONFIGMODE = menuconfig
config: $(LINUX_DIR)/include/linux/autoconf.h
- $(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
- $(MAKE) -C $(LINUX_DIR) ARCH=xen dep
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
clean::
- $(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
delete:
rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR)
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen
--- a/buildconfigs/mk.linux-2.6-xen Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
# The real action starts here!
build: $(LINUX_DIR)/include/linux/autoconf.h
if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
fi
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
$(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
( cd $(LINUX_DIR) ; \
sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
rm -f Makefile ; mv Mk.tmp Makefile )
- $(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
config: CONFIGMODE = menuconfig
config: $(LINUX_DIR)/include/linux/autoconf.h
- $(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
clean::
- $(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
delete:
rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR)
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0 Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen0 Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
# The real action starts here!
build: $(LINUX_DIR)/include/linux/autoconf.h
if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
fi
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
$(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
( cd $(LINUX_DIR) ; \
sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
rm -f Makefile ; mv Mk.tmp Makefile )
- $(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
config: CONFIGMODE = menuconfig
config: $(LINUX_DIR)/include/linux/autoconf.h
- $(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
clean::
- $(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
delete:
rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR)
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xenU
--- a/buildconfigs/mk.linux-2.6-xenU Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xenU Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
# The real action starts here!
build: $(LINUX_DIR)/include/linux/autoconf.h
if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
fi
- $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
$(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
( cd $(LINUX_DIR) ; \
sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
rm -f Makefile ; mv Mk.tmp Makefile )
- $(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
config: CONFIGMODE = menuconfig
config: $(LINUX_DIR)/include/linux/autoconf.h
- $(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
clean::
- $(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+ $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
delete:
rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR)
diff -r ec01850d0ee9 linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree Mon Sep 19 15:21:09 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree Mon Sep 19 10:45:52 2005
@@ -89,6 +89,11 @@
abs_to_rel ${AD} ${AS}
RS=$DESTPATH
+# Arch-specific pre-processing
+if [ -x arch/${LINUX_ARCH}/xen-pre-mkbuildtree ]; then
+ arch/${LINUX_ARCH}/xen-pre-mkbuildtree
+fi
+
# Remove old copies of files and directories at the destination
for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
@@ -110,3 +115,10 @@
cd ${AD}/include/asm-xen/linux-public
ln -sf ../../../${RS}/../tools/xenstore/xenstored.h
+
+# Arch-specific post-processing
+cd ${AD}
+if [ -x arch/${LINUX_ARCH}/xen-post-mkbuildtree ]; then
+ arch/${LINUX_ARCH}/xen-post-mkbuildtree
+fi
+
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 17:39 ` Christian Limpach
0 siblings, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-19 17:39 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On Mon, Sep 19, 2005 at 09:49:05AM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> > we run make ARCH=xen.
> > If you can name your config file xen0_defconfig_ia64 and use
> > LINUX_ARCH for the path, then you won't need to duplicate the config
> > file code.
>
> OK, I see. This cleans it up nicely. New patch attached.
You have to export LINUX_ARCH to the script. We don't want to
unconditionally polute the environment of all the commands we
run, so you'll have to add it to all the calls to mkbuildtree.
I think I'd prefer xen-mkbuildtree-{pre,post} as the name of the scripts
to run, but not too fussed about that...
> Do the changes have no impact to non-Xen non-x86 kernels?
> Since xenlinux/ia64 is transparently paravirtualized,
> the changes looked like they might be xen-specific, and
> xenlinux/ia64 has been running out-of-tree without any
> of those changes, the script moves them aside. If there's
> no impact, I can move them back in (but will probably
> do so slowly for testing purposes).
>
> In any case, drivers/xen definitely is not yet fully
> archdep, so I need to use the pre- or post-mkbuildtree
> to do some patching in the short term. Agree in the longer
> term, these files should be empty but if you don't mind
> greatly, having the archdep hooks there will probably
> make things easier for arch's for now.
Ok, let's go with the pre/post link scripts for now, but I think
it would be good to make our changes work when building non-x86/non-xen.
christian
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 16:09 ` Christian Limpach
0 siblings, 1 reply; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 15:29 UTC (permalink / raw)
To: Jerone Young; +Cc: xen-devel
> On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
>
> > +ifeq ($(ARCH),ia64)
> > + yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
>
> Why are you piping in tons of nothing into Make here using the "yes"
> command?
This mechanically does the same as manually hitting
"enter" at every prompt from "make oldconfig", thus it
applies the default response for every unconfigured
option without manual intervention.
Dan
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 16:09 ` Christian Limpach
0 siblings, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-19 16:09 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: Jerone Young, xen-devel
On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> > On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> > Collins) wrote:
> >
> > > +ifeq ($(ARCH),ia64)
> > > + yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > > +else
> >
> > Why are you piping in tons of nothing into Make here using the "yes"
> > command?
>
> This mechanically does the same as manually hitting
> "enter" at every prompt from "make oldconfig", thus it
> applies the default response for every unconfigured
> option without manual intervention.
I think it's preferable to have default config files which don't cause
any prompting.
Also if people upgrade, they probably want to be prompted on any new
options. If not, then let's get the default behaviour for "make
oldconfig" changed upstream...
christian
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 14:18 ` Christian Limpach
2005-09-19 14:30 ` Jerone Young
0 siblings, 2 replies; 170+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 13:43 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
Attached is an (ugly but relatively simple) patch that allows
Xenlinux/ia64 to be built using the linux "-sparse" tree
methodology (once I populate some files in the -sparse tree).
The changes are not dramatic and I think they can be done
much more cleanly, but I'm not a build expert so would
appreciate improvements from those more comfortable with
the Xen build environment... and perhaps it can be
made more generic so the ppc guys can benefit too.
The primary changes are:
1) wherever a make is done with ARCH=xen, this needs
to be converted to ARCH=ia64. (This can probably
be done as ARCH=$(XENARCH) or something like that
but I'm not sure how to do it without requiring x86
and x86_64 builds to specify XENARCH= at build time.)
2) A sequence of mkbuildtree "massage" commands need to
be executed before mkbuildtree does its linking thing.
Perhaps this could be done as:
if -e mkbuildtree.prelink.$XENARCH
mkbuildtree.prelink.$XENARCH
Though ia64 doesn't need it, maybe also add a "postlink"
equivalent?
There is also one change because the ia64 defconfig filename
is different. I can change this filename to conform with
the existing convention but perhaps the defconfig pathname
could be set as part of the prelink file?
Could someone with the necessary build knowledge make
the improvements and commit this please? Let me know if/when
it goes in and I will populate the ia64 -sparse branches.
Thanks,
Dan
[-- Attachment #2: xenia64sparse --]
[-- Type: application/octet-stream, Size: 3406 bytes --]
diff -r 8d133d172bfd buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0 Sun Sep 18 18:18:57 2005
+++ b/buildconfigs/mk.linux-2.6-xen0 Sun Sep 18 14:31:47 2005
@@ -14,11 +14,19 @@
# The real action starts here!
build: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+ $(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_PATH=$(DESTDIR) install
+ if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
+ $(MAKE) -C $(LINUX_DIR) ARCH=ia64 modules ; \
+ $(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+ fi
+else
if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
$(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
fi
$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+endif
$(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
rm -rf $(LINUX_DIR)
@@ -27,25 +35,45 @@
( cd linux-$(LINUX_SERIES)-xen-sparse ; \
./mkbuildtree ../$(LINUX_DIR) )
# Re-use config from install dir if one exits else use default config
+ifeq ($(ARCH),ia64)
+ CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
+ [ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
+ cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
+ || cp $(LINUX_DIR)/arch/ia64/configs/xen_zx1_defconfig \
+ $(LINUX_DIR)/.config
+else
CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
|| cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARCH) \
$(LINUX_DIR)/.config
+endif
# See if we need to munge config to enable PAE
$(MAKE) CONFIG_FILE=$(LINUX_DIR)/.config -f buildconfigs/Rules.mk config-update-pae
# Patch kernel Makefile to set EXTRAVERSION
( cd $(LINUX_DIR) ; \
sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
rm -f Makefile ; mv Mk.tmp Makefile )
+ifeq ($(ARCH),ia64)
+ yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
+else
$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+endif
config: CONFIGMODE = menuconfig
config: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+ $(MAKE) -C $(LINUX_DIR) $(CONFIGMODE)
+else
$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+endif
clean::
+ifeq ($(ARCH),ia64)
+ $(MAKE) -C $(LINUX_DIR) ARCH=ia64 clean
+else
$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+endif
delete:
rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR)
diff -r 8d133d172bfd linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree Sun Sep 18 18:18:57 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree Sun Sep 18 14:31:47 2005
@@ -92,6 +92,16 @@
# Remove old copies of files and directories at the destination
for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
+if [ "$ARCH" = "ia64" ]; then
+mv arch/xen/kernel drivers/xen/core
+mv mm mm.x86
+mv net net.x86
+mv kernel kernel.x86
+mv arch/xen arch/xen.x86
+mv include/asm-generic include/asm-generic.x86
+mv include/linux include/linux.x86
+fi
+
# We now work from the destination directory
cd ${AD} || { echo "cannot cd to ${AD}"; exit 1; }
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 14:18 ` Christian Limpach
2005-09-19 14:30 ` Jerone Young
1 sibling, 0 replies; 170+ messages in thread
From: Christian Limpach @ 2005-09-19 14:18 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> The primary changes are:
> 1) wherever a make is done with ARCH=xen, this needs
> to be converted to ARCH=ia64. (This can probably
> be done as ARCH=$(XENARCH) or something like that
> but I'm not sure how to do it without requiring x86
> and x86_64 builds to specify XENARCH= at build time.)
Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
we run make ARCH=xen.
If you can name your config file xen0_defconfig_ia64 and use
LINUX_ARCH for the path, then you won't need to duplicate the config
file code.
Please also change all mk.linux files.
> 2) A sequence of mkbuildtree "massage" commands need to
> be executed before mkbuildtree does its linking thing.
> Perhaps this could be done as:
> if -e mkbuildtree.prelink.$XENARCH
> mkbuildtree.prelink.$XENARCH
> Though ia64 doesn't need it, maybe also add a "postlink"
> equivalent?
Why do you need to move these out of the way in the first place? If
any of the changes we've made break ia64, then we should cleanup our
changes.
> Could someone with the necessary build knowledge make
> the improvements and commit this please? Let me know if/when
> it goes in and I will populate the ia64 -sparse branches.
Please give creating a patch another try, taking the suggestions above
into consideration. Thanks!
christian
^ permalink raw reply [flat|nested] 170+ messages in thread* Re: (no subject)
2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 14:18 ` Christian Limpach
@ 2005-09-19 14:30 ` Jerone Young
2005-09-19 15:34 ` Mark Williamson
1 sibling, 1 reply; 170+ messages in thread
From: Jerone Young @ 2005-09-19 14:30 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel
On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> +ifeq ($(ARCH),ia64)
> + yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> +else
Why are you piping in tons of nothing into Make here using the "yes"
command?
--
Jerone Young
IBM Linux Technology Center
jyoung5@us.ibm.com
512-838-1157 (T/L: 678-1157)
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2005-09-19 14:30 ` Jerone Young
@ 2005-09-19 15:34 ` Mark Williamson
0 siblings, 0 replies; 170+ messages in thread
From: Mark Williamson @ 2005-09-19 15:34 UTC (permalink / raw)
To: xen-devel; +Cc: Magenheimer, Dan (HP Labs Fort Collins), Jerone Young
> Collins) wrote:
> > +ifeq ($(ARCH),ia64)
> > + yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
>
> Why are you piping in tons of nothing into Make here using the "yes"
> command?
I guess, to answer <ret> (choose default) to any questions oldconfig throws
up.
Cheers,
Mark
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-07-05 22:54 Igor Feoktistov
0 siblings, 0 replies; 170+ messages in thread
From: Igor Feoktistov @ 2005-07-05 22:54 UTC (permalink / raw)
To: xen-devel
Hi,
has anybody tried linux-iscsi-4.0.2 with linux-2.6.11-xen0?
scsi-transport-iscsi failed to compile due to different structure
definitions in scsi_transport_iscsi.h
Using scsi-transport-iscsi from linux-2.6.11-xen0 distro I was able
to open iscsi session. However, there is tons of kernel errors like below.
Any ideas how to cure it?
--
Jul 5 15:18:31 iscsi-rh4u1 kernel: SCSI device sdc: 73400320 512-byte hdwr sectors (375
Jul 5 15:18:31 iscsi-rh4u1 kernel: Badness in local_bh_enable at kernel/softirq.c:140
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c011e495>] local_bh_enable+0x68/0x89
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c896a742>] iscsi_queuecommand+0x173/0x1e3 [iscsi_
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c029c2f8>] scsi_dispatch_cmd+0x140/0x22e
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c029c53a>] scsi_done+0x0/0x26
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c029ebdb>] scsi_times_out+0x0/0xa0
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c02a19de>] scsi_request_fn+0x234/0x452
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c0227bda>] __elv_add_request+0x84/0xb1
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c022a708>] blk_insert_request+0xd7/0x104
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c02a05aa>] scsi_insert_special_req+0x3a/0x40
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c02a07f2>] scsi_wait_req+0x69/0x9b
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c02a06ef>] scsi_wait_done+0x0/0x9a
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c02a1e1d>] __scsi_mode_sense+0xc7/0x286
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c0119be3>] vprintk+0x140/0x1b7
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c030fc98>] sd_read_cache_type+0x5f/0x216
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c029bce8>] scsi_allocate_request+0x28/0x62
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c030ff48>] sd_revalidate_disk+0xf9/0x131
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c030fe4f>] sd_revalidate_disk+0x0/0x131
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c030ea83>] sd_open+0x0/0xf0
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c0185201>] rescan_partitions+0xdd/0x103
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c030ea83>] sd_open+0x0/0xf0
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c015b05c>] do_open+0x2a7/0x390
Jul 5 15:18:31 iscsi-rh4u1 kernel: [<c015b1c8>] blkdev_get+0x83/0x8e
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-06-26 3:26 Reiner Sailer
0 siblings, 0 replies; 170+ messages in thread
From: Reiner Sailer @ 2005-06-26 3:26 UTC (permalink / raw)
To: Anthony Liguori; +Cc: xen-devel, Stefan Berger
> Message: 4
> Date: Sat, 25 Jun 2005 19:21:21 -0500
> From: Anthony Liguori <aliguori@us.ibm.com>
> Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0
> To: Stefan Berger <stefanb@us.ibm.com>
> Cc: xen-devel@lists.xensource.com
> Message-ID: <42BDF501.4090502@us.ibm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Please make sure to increment the DOM0_INTERFACE_VERSION when this is
> committed.
Correct. The DOM0 interface treats "non-existing" ssidref configurations
now
differently (sets them to 0 instead of ffffffff).
>
> Anthony Liguori
>
> Stefan Berger wrote:
Thanks
Reiner
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-04-28 4:11 田冠华
0 siblings, 0 replies; 170+ messages in thread
From: 田冠华 @ 2005-04-28 4:11 UTC (permalink / raw)
To: xen-devel
Hello ，
I am interested in Xen project,but I am a stranger .
I think it is helpful to read the emails which the other participationers have posted .
Could you post me some emails in which other people discussed about Xen project
Best wishes
tianguanhua@ncic.ac.cn
2005-04-28
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2005-04-28 4:10 田冠华
0 siblings, 0 replies; 170+ messages in thread
From: 田冠华 @ 2005-04-28 4:10 UTC (permalink / raw)
To: xen-devel
Hello ，
I am interested in Xen project,but I am a stranger .
I have got the code of Xen project,but there is no explanation in the lines ,I can not understand the code ,
Could you give me a document about software construction of Xen project ,including how many modules ,how these modules are organised and etc.
Who have designed the CPU modules ,can you shou me a light on how you organise the CPU modules?
Best wishes
tianguanhua@ncic.ac.cn
2005-04-28
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2005-04-18 16:43 tarawa1943
2005-04-18 17:07 ` Keir Fraser
0 siblings, 1 reply; 170+ messages in thread
From: tarawa1943 @ 2005-04-18 16:43 UTC (permalink / raw)
To: m+Ian.Pratt; +Cc: xen-devel, christopher.w.clark
Ian
Thank you sir, I will check that. I did do another build with 12apr05 xen-unstable and it did not have the same symptom/problem, xen-unstable changed around 16-17apr05, to expose this symptom on a thinkpad. Will look deeper.
woody
========================================
Date: Mon, 18 Apr 2005 10:26:16 +0100
From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] "Floppy drive(s): fd0 is 1.44M"
To: <tarawa1943@comcast.net>, <xen-devel@lists.xensource.com>
Cc: christopher.w.clark@gmail.com
Message-ID:
<A95E2296287EAD4EB592B5DEEFCE0E9D1E3BF4@liverpoolst.ad.cl.cam.ac.uk>
Content-Type: text/plain; charset="us-ascii"
> Subject: [Xen-devel] "Floppy drive(s): fd0 is 1.44M"
>
> Thanks for your response, and how would you suggest that one
> would fix that?
> It hangs in the boot process!
Have you tried messing with the 'floppy=' parameter on the kernel
command line?
See Documentation/floppy.txt
Alternatively, just config the driver out of your kernel, to confirm
that this is what is causing the hang.
We use the floppy driver in PIO rather than DMA mode, and this is must
be causing the probe code to get confused under some circumstances.
(thinkpad floppy drives are somewhat notorious, and there's lots of work
arounds in the probe code)
Ian
^ permalink raw reply [flat|nested] 170+ messages in thread
* Re: (no subject)
2005-04-18 16:43 tarawa1943
@ 2005-04-18 17:07 ` Keir Fraser
0 siblings, 0 replies; 170+ messages in thread
From: Keir Fraser @ 2005-04-18 17:07 UTC (permalink / raw)
To: tarawa1943; +Cc: m+Ian.Pratt, xen-devel, christopher.w.clark
On 18 Apr 2005, at 17:43, tarawa1943@comcast.net wrote:
> Thank you sir, I will check that. I did do another build with 12apr05
> xen-unstable and it did not have the same symptom/problem,
> xen-unstable changed around 16-17apr05, to expose this symptom on a
> thinkpad. Will look deeper.
Not that much has been checked in since then. You could try backing out
the local APIC code changes (checked in on 16th April) but even that
seems unlikely to break the floppy driver, I think.
-- Keir
^ permalink raw reply [flat|nested] 170+ messages in thread
* RE: (no subject)
@ 2005-01-22 16:20 Ian Pratt
0 siblings, 0 replies; 170+ messages in thread
From: Ian Pratt @ 2005-01-22 16:20 UTC (permalink / raw)
To: Adam Heath, xen-devel
> ps: I decided to split out these patches, and send upstream,
> before uploading
> my deb packages. If possible, I'd like to have these
> applied, and a new
> version rolled based on them.
I like all the patches. Any comments from anyone else?
I guess there's enough fixes in 2.0-testing to warrant a release, but
I'd like to leave all the patches in testing for a couple of days to get
exercised.
Ian
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-01-21 17:38 Adam Heath
0 siblings, 0 replies; 170+ messages in thread
From: Adam Heath @ 2005-01-21 17:38 UTC (permalink / raw)
To: xen-devel
===
Name: proper-depends.patch
Description: Use proper targets in makefiles
A rule in make should produce only what it's target allows. When it
produces side-effects, things like ctrl-c and parallellism break it
oddly.
DiffStat:
xen/Makefile | 9 +++++----
xen/arch/x86/Makefile | 14 ++++++++++----
xen/common/Makefile | 3 ++-
xen/drivers/acpi/Makefile | 3 ++-
xen/drivers/char/Makefile | 3 ++-
xen/drivers/pci/Makefile | 3 ++-
6 files changed, 23 insertions(+), 12 deletions(-)
===
Description: Use proper targets in makefiles
A rule in make should produce only what it's target allows. When it
produces side-effects, things like ctrl-c and parallellism break it
oddly.
--- xen-2.0.3.orig/xen/arch/x86/Makefile
+++ xen-2.0.3/xen/arch/x86/Makefile
@@ -12,12 +12,18 @@
OBJS := $(subst $(TARGET_SUBARCH)/asm-offsets.o,,$(OBJS))
-default: boot/$(TARGET_SUBARCH).o $(OBJS) boot/mkelf32
- $(LD) $(LDFLAGS) -r -o arch.o $(OBJS)
- $(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
- boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $(TARGET)-syms
+default: $(TARGET)
+
+$(TARGET): $(TARGET)-syms boot/mkelf32
./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000
+$(CURDIR)/arch.o: $(OBJS)
+ $(LD) $(LDFLAGS) -r -o $@ $(OBJS)
+
+$(TARGET)-syms: boot/$(TARGET_SUBARCH).o $(ALL_OBJS) $(TARGET_SUBARCH)/xen.lds
+ $(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
+ boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $@
+
asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(CFLAGS) -S -o $@ $<
--- xen-2.0.3.orig/xen/common/Makefile
+++ xen-2.0.3/xen/common/Makefile
@@ -19,7 +19,8 @@
OBJS := $(subst trace.o,,$(OBJS))
endif
-default: $(OBJS)
+default: common.o
+common.o: $(OBJS)
$(LD) $(LDFLAGS) -r -o common.o $(OBJS)
clean:
--- xen-2.0.3.orig/xen/drivers/pci/Makefile
+++ xen-2.0.3/xen/drivers/pci/Makefile
@@ -28,7 +28,8 @@
#obj-y += syscall.o
#endif
-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)
clean:
--- xen-2.0.3.orig/xen/drivers/char/Makefile
+++ xen-2.0.3/xen/drivers/char/Makefile
@@ -1,7 +1,8 @@
include $(BASEDIR)/Rules.mk
-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)
clean:
--- xen-2.0.3.orig/xen/drivers/acpi/Makefile
+++ xen-2.0.3/xen/drivers/acpi/Makefile
@@ -6,7 +6,8 @@
OBJS := acpi_ksyms.o tables.o
-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)
clean:
--- xen-2.0.3.orig/xen/Makefile
+++ xen-2.0.3/xen/Makefile
@@ -9,14 +9,15 @@
include Rules.mk
-default: $(TARGET)
- gzip -f -9 < $(TARGET) > $(TARGET).gz
+default: $(TARGET).gz
+$(TARGET).gz: $(TARGET)
+ gzip -f -9 < $< > $@.new
+ mv $@.new $@
debug:
objdump -D -S $(TARGET)-syms > $(TARGET).s
-install: $(TARGET)
- gzip -f -9 < $(TARGET) > $(TARGET).gz
+install: $(TARGET).gz
mkdir -p $(prefix)/boot
install -m0644 $(TARGET).gz $(prefix)/boot
install -m0644 $(TARGET)-syms $(prefix)/boot
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2005-01-21 17:35 Adam Heath
0 siblings, 0 replies; 170+ messages in thread
From: Adam Heath @ 2005-01-21 17:35 UTC (permalink / raw)
To: xen-devel
I spent last night and this morning splitting the single patch I had, into 13
separate patches. Most are build system tweaks(DESTDIR, parallel make,
INSTALL, proper target depends). Also, proper PIC support in the libs, and a
few other things.
Below is the meta-info that my patch oriented build system maintains. I'll be
sending each patch as a separate mail(I apologize for the mail flood ahead of
time).
ps: I decided to split out these patches, and send upstream, before uploading
my deb packages. If possible, I'd like to have these applied, and a new
version rolled based on them.
pps: These are generated against 2.0.3.
===
Name: proper-depends.patch
Description: Use proper targets in makefiles
A rule in make should produce only what it's target allows. When it
produces side-effects, things like ctrl-c and parallellism break it
oddly.
DiffStat:
xen/Makefile | 9 +++++----
xen/arch/x86/Makefile | 14 ++++++++++----
xen/common/Makefile | 3 ++-
xen/drivers/acpi/Makefile | 3 ++-
xen/drivers/char/Makefile | 3 ++-
xen/drivers/pci/Makefile | 3 ++-
6 files changed, 23 insertions(+), 12 deletions(-)
Name: pic-lib.patch
Description: support PIC code generation
Libraries have 2 methods of being compiled; a .so must contain non-pic
objects, while the .a can contain standard objects.
DiffStat:
tools/libxc/Makefile | 34 +++++++++++++++++++++-------------
tools/libxutil/Makefile | 11 ++++++++---
2 files changed, 29 insertions(+), 16 deletions(-)
Name: doc-make-vars.patch
Description: Use vars for complex programs
It's generally standard to call complex programs indirectly thru make
variables. This allows them to be replaced easily with alternative
versions, without editting each makefile.
.
Additionally, this patch makes use of $(pkgdocdir) in docs/Makefile.
DiffStat:
docs/Makefile | 53 +++++++++++++++++++++++++++++++++++------------------
1 files changed, 35 insertions(+), 18 deletions(-)
Name: INSTALL.patch
Depends: proper-depends.patch, pic-lib.patch, doc-make-vars.patch
Description: use INSTALL everywhere
Use install(by way of INSTALL variables) to create directories, install
programs, and install data files.
DiffStat:
Makefile | 22 +++++++++++++---------
docs/Makefile | 10 ++++++----
tools/examples/Makefile | 20 ++++++++++++--------
tools/libxc/Makefile | 12 ++++++++----
tools/libxutil/Makefile | 9 +++++++--
tools/misc/Makefile | 11 +++++++----
tools/misc/miniterm/Makefile | 7 +++++--
tools/sv/Makefile | 18 ++++++++++--------
tools/xentrace/Makefile | 16 ++++++++++------
tools/xfrd/Makefile | 8 ++++++--
xen/Makefile | 17 ++++++++++-------
11 files changed, 94 insertions(+), 56 deletions(-)
Name: bash-for-mkbuildtree.patch
Description: mkbuildtree requires bash
DiffStat:
linux-2.4.28-xen-sparse/mkbuildtree | 2 +-
linux-2.6.10-xen-sparse/mkbuildtree | 2 +-
netbsd-2.0-xen-sparse/mkbuildtree | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Name: parallel-make.patch
Depends: INSTALL.patch, proper-depends.patch
Description: support parallellism better
Using shell for loops doesn't allow make to run it the most parallel
modes. Use patsubst/addsuffix tricks to make this work.
DiffStat:
Makefile | 60 +++++++++++++++++++++++------------------------------------
xen/Makefile | 9 +++-----
2 files changed, 28 insertions(+), 41 deletions(-)
Name: init-script-force-reload.patch
Description: add force-reload option
Debian policy requires init scripts to implement force-reload. So, alias
that to restart.
DiffStat:
tools/examples/init.d/xend | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Name: fhs-paths.patch
Depends: INSTALL.patch
Description: Use FHS-compatible paths
DiffStat:
tools/python/xen/sv/params.py | 4 ++--
tools/python/xen/xend/XendRoot.py | 2 +-
tools/sv/Makefile | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
Name: linux-2.4-modules.patch
Description: conditionally call modules targets for 2.4
There was a complaint on the mailing list about linux 2.6 not building
if module support was disabled; a patch was done to fix this. However,
the same change was not done to the 2.4 files.
DiffStat:
buildconfigs/mk.linux-2.4-xen0 | 6 ++++--
buildconfigs/mk.linux-2.4-xenU | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
Name: python-path.patch
Description: fix path to python
There is no python2 in debian. Instead, use python.
DiffStat:
tools/python/xen/xend/server/SrvServer.py | 2 +-
tools/python/xen/xend/sxp.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Name: prefix-DESTDIR.patch
Depends: INSTALL.patch, doc-make-vars.patch, fhs-paths.patch, linux-2.4-modules.patch, parallel-make.patch, pic-lib.patch, proper-depends.patch
Description: use DESTDIR correctly
Standard makefiles always attempt to install to the root(/). Setting
DESTDIR is the normal way to install to an alternative location.
.
Setting prefix has the possibility of breaking programs, as the prefix
may have been embedded inside a compiled binary.
DiffStat:
Makefile | 11 ++++++-----
buildconfigs/mk.linux-2.4-xen0 | 4 ++--
buildconfigs/mk.linux-2.4-xenU | 4 ++--
buildconfigs/mk.linux-2.6-xen0 | 4 ++--
buildconfigs/mk.linux-2.6-xenU | 4 ++--
docs/Makefile | 13 +++++++------
tools/examples/Makefile | 20 ++++++++++----------
tools/libxc/Makefile | 12 ++++++------
tools/libxutil/Makefile | 8 ++++----
tools/misc/Makefile | 8 ++++----
tools/misc/miniterm/Makefile | 4 ++--
tools/python/Makefile | 6 ++----
tools/sv/Makefile | 14 +++++++-------
tools/xentrace/Makefile | 12 ++++++------
tools/xfrd/Makefile | 4 ++--
xen/Makefile | 20 ++++++++++----------
16 files changed, 74 insertions(+), 74 deletions(-)
Name: sane-make-syntax.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch
Description: fix non-standard make/shell syntax
Fix use of `pwd`, &&, and || true. Also, remove ().
DiffStat:
Makefile | 16 ++++++++--------
tools/Makefile | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
Name: xen-banner.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch, proper-depends.patch
Description: split banner.h
Split banner.h, to make it easier to edit, and more properly fit in with
normal build systems.
.
Also, inline the rules to actually build figlet.
DiffStat:
xen/Makefile | 50 +++++++++++++++++++++++--------------------
xen/include/xen/banner.h | 12 ++++++++++
xen/include/xen/compile.h.in | 13 +++++++++++
3 files changed, 52 insertions(+), 23 deletions(-)
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
^ permalink raw reply [flat|nested] 170+ messages in thread* (no subject)
@ 2004-12-31 15:43 M.A. Williamson
0 siblings, 0 replies; 170+ messages in thread
From: M.A. Williamson @ 2004-12-31 15:43 UTC (permalink / raw)
To: amitabh_2k; +Cc: xen-devel
All these problems are to be expected - the guest can't make privileged
access to the machine's hardware so updating microcode, clock, etc won't
work. I'm not actually sure what "keytable" does but it doesn't look like
it's needed ;-), gpm is definitely not needed.
It's nothing to worry about - you should just disable these services so
that they don't get run. e.g. on Redhat something like
# chkconfig --del servicename
for each service. Or use you favourite console / GUI admin tool.
As mentioned in another post, the microcode update seems to be trying to
load the module for the wrong kernel version (which is odd). Even if it
were the right version, it still wouldn't work...
Cheers,
Mark
> 1) Applying Intel IA32 Microcode update: insmod:
> /lib/modules/2.6.5-7.97-smp/kernel/arch/i386/kernel/microcode.o: insmod
> char-major-10-184 failed
>
> 2) Starting keytable: Loading keymap: /etc/rc5.d/S17keytable: line 26:
> /dev/tty0: No such device
> [FAILED]
>
> 3) Starting console mouse services: gpm: oops() invoked from gpn.c(132)
> loadlut: is your kernel compiled with CONFIG_SELECTION on?: Invalid
> argument [FAILED] (This is probably because the initial OS installation
> was configured to have a graphical interface)
>
> During Halt:
> 1) Sending all processes the KILL signal...
> Syncing hardware clock to system time modprobe: modprobe: Can't locate
> module char-major-10-135
> hwclock is unable to get I/O port access: the iopl(3) call failed.
>
> Guest OS boots-up and halts fine. (except for the above errors)
>
> Any suggesstions??
>
> Thanks,
>
> Amitabh
>
>
> From: "M.A. Williamson" <maw48@cam.ac.uk>
> Reply-To: maw48@cantab.net
> To: "Fajar A. Nugraha" <fajar@telkom.co.id>
> CC: Amitabh Tamhane <amitabh_2k@hotmail.com>,
> xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Porting of Guest OS
> Date: 30 Dec 2004 14:50:25 +0000
>
> > > The exact error I am getting is: Could not find LABLE=/ and boots in
> > > >
> >the "repair filesystem" mode.
> >
> > that's /etc/fstab allright. Change the line that says LABEL=/ to
> > /dev/sda1. You might also need to remove the line that mounts /boot For
> > kernel-2.6-based or nptl-enabled distro, you also need to remove
> > /lib/tls and /usr/lib/tls on the domain root file system (Xen will tell
> > you to do this when it boots).
>
> Using LABEL=blah requires a) you to set the label on the disk file you
> created b) you to boot with a suitable initrd (e.g. one that came with
> your distro) to perform the lookup of filesystem labels.
>
> You will find it easier to get stuff working if you just specify
> /dev/whatever explicitly in the config file and edit the guest fstab to
> match.
>
> > > The guest OS could talk with the outside world but `xm list` command
> > > >
> >shows state as -b--- (blocked) for the domain I am trying to boot.
> > >
> >Is that what "-b---" means? All my virtual domains shows that, and yet
> >they're working perfectly.
>
> If they're not doing work on the CPU at this instant then they're
> probably blocked - unless they're doing something CPU intensive they'll
> be in that state a lot.
>
> If you've only got one CPU then you'll never see another domain in the
> running state - the fact that dom0 is running at this instant implies
> that the other domains aren't :-)
>
> HTH,
> Mark
>
>
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2004-08-20 12:09 James Harper
0 siblings, 0 replies; 170+ messages in thread
From: James Harper @ 2004-08-20 12:09 UTC (permalink / raw)
To: xen-devel@lists.sourceforge.net
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
It's actually xenU I want to test it in (but compiling under xen0), and a make says this:
Note: using kernel source from /lib/modules/2.6.7-xen0/build containing
kernel version 2.6.7
Note: using kernel config from /boot/config-2.6.7-xen0
So i set TOPDIR too, and also had to patch iscsi-id.c to fix these two errors:
iscsi-id.c:90: error: too few arguments to function `sysfs_open_class_device'
iscsi-id.c:94: error: too few arguments to function `sysfs_open_class_device'
by changing the calls to sysfs_open_class_device_path. hope that's the right thing to do. I must have a different version of sysfs (debian version is 1.1.0-1)
'make ARCH=xen' seems to do the right thing, but 'make ARCH=xen install' says:
Installing iSCSI driver for Linux 2.6.7-xen0
doh!
then I replaced all occurences of 'shell uname -r' in the makefile with 'shell echo 2.6.7-xenU'
and it compiles finally. The only problem is that I just did a bk pull and enabled SCSI in xenU, and now the kernel won't compile. i've attached the output of 'make linux26' (but it got rejected so i'm posting it without), the errors are to do with undefined references to 'direct_remap_area_pages'. Do you think that it is to do with the latest bk pull or to do with me enabling device drivers in an unprivileged kernel?
i'll get there eventually!
thanks
James
[-- Attachment #2: Type: text/html, Size: 2362 bytes --]
^ permalink raw reply [flat|nested] 170+ messages in thread
* (no subject)
@ 2004-04-19 7:27 Jan van Rensburg
0 siblings, 0 replies; 170+ messages in thread
From: Jan van Rensburg @ 2004-04-19 7:27 UTC (permalink / raw)
To: xen-devel, brianw
Brian,
I've done basically the same thing with the Xen FAQ. I've watched the
list and updated the FAQ as new questions came along. In order to
centralize the Xen documentation, won't you pull the Xen FAQ into the
wiki? It can be found here:
http://xen.epiuse.com/xen-faq.txt
Once you're done that I'll replace the FAQ with an automatic redirect
to your page. The FAQ was last updated about 3 months ago (Sorry
everybody about that! Work got a bit hectic).
Jan
> Message: 1
> Date: Sun, 18 Apr 2004 12:31:02 -0500 (CDT)
> From: "Brian Wolfe" <brianw@terrabox.com>
> To: xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] xen wiki site available http://xen.terrabox.com
>
> http://xen.terrabox.com
>
> I will attempt to keep the site updated based on the xen-devel list
> traffic. If anyone wants to contribute, feel free. Eventually I will
> get
> the main sections locked down. But until then, i'm leaving them open so
> that anyone that gets bored can easilly update, correct, etc what I
> have
> up there.
>
> The ultimate goal of the wiki site is to provide as much information
> about
> Xen as possible in a format that is easilly understood.
>
> Curent sections planned:
> Resource links as the homepage (downloads, official docs, Distro
> Packages, FAQs, mailing lists, companies offering xen based hosting)
> Documentation: Official text files, paginated with cross links, and
> man
> pages of every program/daemon/config file.
> Debian Packages: sources.list entries
> Xen FAQ: Standard paginated faq of common questions from xen-devel.
> Mailing Lists: list of sites archiving xen mailing lists and
> subscription management links.
> Companies offering xen hosting: table of company, url, price range,
> and
> notes.
>
> It is my ultimate goal to provide an easilly maintained resource that
> will
> serve as the basis of the end user/administrator documentation as well
> as
> FAQ and other associated resources.
>
> Any advice is desired and welcome, especially considering that I am
> new to
> phpwiki. :)
>
> --
> Brian Wolfe | Phone 1-(214)-764-1204
> President, | Email brianw@terrabox.com
> TerraBox.com Inc. |
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
^ permalink raw reply [flat|nested] 170+ messages in thread
end of thread, other threads:[~2018-11-19 17:34 UTC | newest]
Thread overview: 170+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-27 19:20 [RFC PATCH v3.1] xSplice design Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
2015-07-30 16:47 ` Johannes Erdfelt
2015-07-31 15:46 ` Konrad Rzeszutek Wilk
2015-08-11 14:17 ` Jan Beulich
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
2015-07-28 15:51 ` Andrew Cooper
2015-07-28 16:35 ` Konrad Rzeszutek Wilk
2015-08-05 8:50 ` Martin Pohlack
2015-08-05 8:58 ` Andrew Cooper
2015-08-05 13:27 ` Martin Pohlack
2015-08-05 14:06 ` (no subject) Martin Pohlack
2015-08-05 14:09 ` [PATCH] xsplice: Use ld-embedded build-ids Martin Pohlack
2015-08-11 14:12 ` Jan Beulich
2015-08-14 12:59 ` Martin Pohlack
2015-08-14 13:54 ` Jan Beulich
2015-08-14 13:57 ` Martin Pohlack
2015-09-15 18:38 ` Konrad Rzeszutek Wilk
2015-08-11 14:02 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Jan Beulich
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
2015-08-05 13:25 ` Hotpatch construction and __LINE__ Andrew Cooper
2015-08-12 8:09 ` Jan Beulich
2015-08-12 9:55 ` Andrew Cooper
2015-11-03 18:21 ` Ross Lagerwall
-- strict thread matches above, loose matches on Subject: below --
2018-11-19 17:26 (no subject) Razvan Cojocaru
2018-11-19 17:34 ` Razvan Cojocaru
2017-11-15 15:29 futurelieswithin
2017-08-25 5:16 Chao Gao
2017-07-28 5:27 Manonmani
2017-07-26 19:04 Raviprasad Gurikar
2017-04-04 11:29 Seraphime Kirkovski
2017-02-27 18:12 Dmitry Rockosov
2017-03-06 10:48 ` George Dunlap
2017-02-17 17:17 dhara buch
2017-02-20 17:56 ` Dario Faggioli
2017-02-17 10:47 Norbert Manthey
2017-02-17 11:35 ` Andrew Cooper
[not found] <1484304406-10820-2-git-send-email-nicolas.dichtel@6wind.com>
[not found] ` <3131144.4Ej3KFWRbz@wuerfel>
[not found] ` <1484304406-10820-1-git-send-email-nicolas.dichtel@6wind.com>
2017-01-13 15:36 ` David Howells
2017-01-13 15:43 ` David Howells
2016-12-29 0:56 Ronald Rojas
2017-01-04 1:10 ` Stefano Stabellini
2016-11-28 17:18 Ronald Rojas
2016-07-16 11:51 姚 å¿ å°†
2016-07-07 9:36 George Dunlap
2016-07-07 11:03 ` Dario Faggioli
2016-07-07 12:48 ` George Dunlap
2016-07-07 15:42 ` Dario Faggioli
2016-10-31 10:33 ` Ian Jackson
2016-05-19 14:34 Roger Pau Monné
2016-03-17 12:20 Safa Hamza
2016-03-18 11:34 ` Safa Hamza
2016-02-25 12:38 Ayushi Arora
2015-12-07 17:27 Ian Jackson
2015-01-06 17:17 Konrad Rzeszutek Wilk
2014-12-19 9:53 Minalkumar Patel
2014-12-19 9:59 ` Ian Campbell
2014-02-13 23:47 Zir Blazer
2014-02-13 16:01 Simon Martin
2014-02-13 16:10 ` Andrew Cooper
2014-02-13 17:27 ` Don Slutz
2013-12-31 15:15 Konrad Rzeszutek Wilk
2013-12-17 18:35 Ian Jackson
2013-12-18 11:19 ` George Dunlap
2013-12-18 13:35 ` Ian Campbell
2014-01-07 13:55 ` Ian Campbell
2013-12-15 7:58 Adel Amani
2013-11-13 19:02 Jim Durand
2013-11-18 14:17 ` George Dunlap
2013-09-13 16:59 David Vrabel
2013-08-14 2:28 yvxiang
2013-08-14 2:31 ` yvxiang
2013-08-14 2:57 ` agya naila
2013-07-04 11:32 Tim Deegan
2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
2013-07-04 11:44 ` (no subject) Tim Deegan
2013-06-26 11:42 Divya Kapil
2013-06-26 11:54 ` Ian Campbell
2013-06-16 13:45 wei.liu2
2013-05-14 15:11 Feng Tang
2013-05-03 8:48 Lars Kurth
2013-04-21 22:26 Lonnie Cumberland
[not found] <CAHyyzzTtK+LbxOh2r_X0=Zd2FsTxoAiLLaWahv5FY-QZnQxhLQ@mail.gmail.com>
[not found] ` <CAHyyzzSO0vY3LquDjXVAeV3U9sLnAY28+iADzsOLFkMGcJHLOQ@mail.gmail.com>
[not found] ` <CAHyyzzSDqmBNWmyRKFijei8YrJD5i40AJ9mcxxnme9CeCLZX2g@mail.gmail.com>
[not found] ` <CAHyyzzQcjzeWv-Z6SBOb8Ra0u6BOMzjKV3Ze482rMmMHkAMccw@mail.gmail.com>
[not found] ` <CAHyyzzQsh30y7-4M1xmJc+8p-EcqS0+jaibpTrXxTQi92iGDgw@mail.gmail.com>
2013-04-10 15:28 ` jacek burghardt
2013-04-10 6:57 Mina Jafari
2013-03-15 7:40 digvijay chauhan
2013-03-15 9:59 ` Ian Campbell
2013-03-15 11:18 ` Pasi Kärkkäinen
2013-01-08 21:51 Rushikesh Jadhav
2012-11-15 12:08 Tim Deegan
2012-11-15 23:04 ` Aravindh Puthiyaparambil
2013-04-22 21:56 ` Cutter 409
2013-04-23 8:49 ` Tim Deegan
2012-07-27 23:02 lmw
2012-07-14 4:16 张智
2012-07-19 10:24 ` Tim Deegan
2012-04-15 6:09 Lin Ming
2012-04-05 18:26 Francisco Rocha
2012-04-05 19:36 ` Wei Huang
2012-04-05 20:17 ` Francisco Rocha
2012-04-05 20:27 ` Wei Huang
2012-04-05 20:43 ` Francisco Rocha
2012-04-06 14:53 ` Francisco Rocha
2012-04-06 14:51 ` Wei Huang
2012-04-06 15:02 ` Francisco Rocha
2012-04-06 15:14 ` Konrad Rzeszutek Wilk
2012-04-06 16:09 ` Francisco Rocha
2012-02-24 18:54 Ian Jackson
2012-02-17 19:15 Ian Jackson
2011-10-17 7:40 Paolo Bonzini
2011-10-17 17:05 ` Konrad Rzeszutek Wilk
2011-10-17 21:02 ` Ian Campbell
2011-10-18 7:13 ` Paolo Bonzini
2011-10-06 13:11 Pratik shinde
2011-10-06 13:18 ` Andrew Cooper
2011-07-27 8:33 Grant McWilliams
2011-06-21 3:39 Attila Jecs
2011-06-21 13:20 ` Konrad Rzeszutek Wilk
2011-04-04 6:18 Novik, Alex
2011-03-20 22:27 Keshav Darak
2010-11-16 11:12 Ken Ash
2010-10-07 2:46 Mike Viau
2010-10-07 10:43 ` Stefano Stabellini
2010-10-07 13:43 ` George Shuklin
2010-10-07 14:21 ` Ian Campbell
2010-10-07 16:54 ` George Shuklin
2010-10-07 14:02 ` Ian Campbell
2010-04-16 10:59 Jiang, Yunhong
2009-10-09 21:47 Eads, Joshua Michael (S&T-Student)
2009-01-23 6:45 Alexia Benington
2008-11-19 22:29 Bowen, Clair
2008-11-19 22:36 ` James Harper
2008-10-10 12:27 Swapna Shingre
2008-09-18 7:10 James Song
2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
2007-06-11 10:53 ` pradeep singh rautela
2006-10-09 11:55 Timo Benk
2006-07-17 14:44 Li, Xin B
2006-06-07 23:48 vineet chadha
2006-06-02 13:23 Kevin Tronkowski
2006-04-06 22:26 Nivedita Singhvi
2006-02-10 8:55 Li, Xin B
2005-11-19 22:44 Purav Saraiya
2005-10-02 2:59 Prashanth Radhakrishnan
2005-09-29 5:55 Li, Chengyuan
2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-24 0:28 ` Christian Limpach
2005-09-21 20:49 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 21:18 ` Christian Limpach
2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 19:58 ` Christian Limpach
2005-09-19 16:57 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 17:39 ` Christian Limpach
2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 16:09 ` Christian Limpach
2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 14:18 ` Christian Limpach
2005-09-19 14:30 ` Jerone Young
2005-09-19 15:34 ` Mark Williamson
2005-07-05 22:54 Igor Feoktistov
2005-06-26 3:26 Reiner Sailer
2005-04-28 4:11 田冠华
2005-04-28 4:10 田冠华
2005-04-18 16:43 tarawa1943
2005-04-18 17:07 ` Keir Fraser
2005-01-22 16:20 Ian Pratt
2005-01-21 17:38 Adam Heath
2005-01-21 17:35 Adam Heath
2004-12-31 15:43 M.A. Williamson
2004-08-20 12:09 James Harper
2004-04-19 7:27 Jan van Rensburg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).