[Xen-devel] [PATCH] x86/hvm: Fix deadlock in emulation of rep mov to or from VRAM.
Razvan Cojocaru reported a hypervisor deadlock with the following stack:
(XEN)[82d08012c3f1] _spin_lock+0x31/0x54
(XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125
(XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a
(XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67
(XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d
(XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16
(XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6
(XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b
(XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1
(XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163
(XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26
(XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335
(XEN)[82d080198b49] x86_emulate+0x56c9/0x13088
(XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281
(XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12
(XEN)[82d0801cb63e] handle_mmio+0x54/0xd2
(XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46
(XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589
(XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d
(XEN)[82d0801ee7d1] vmx_asm_vmexit_handler+0x41/0xc0
The problem here is the call to hvm_mmio_internal() being made by
__hvm_copy().
When the emulated VRAM access was originally started by
hvm_io_intercept() a few frames up the stack, it would have called
stdvga_mem_accept() which would then have acquired the per-domain
stdvga lock. Unfortunately the call to hvm_mmio_internal(), to avoid
a costly P2M walk, speculatively calls stdvga_mem_accept() again to
see if the page handed to __hvm_copy() is actually an internally
emulated page and hence the vcpu deadlocks.
The fix is to do the range-check in stdvga_mem_accept() without taking
the stdvga lock. This is safe because the range is constant and we know
the I/O will never actually be accepted by the stdvga device model
because hvmemul_do_io_addr() makes sure that the source of the I/O is
actually RAM.
Reported-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
xen/arch/x86/hvm/stdvga.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/stdvga.c b/xen/arch/x86/hvm/stdvga.c
index ebb3b42..6306fa2 100644
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
hvm_io_handler *handler,
{
struct hvm_hw_stdvga *s = current-domain-arch.hvm_domain.stdvga;
+/*
+ * The range check must be done without taking the lock, to avoid
+ * deadlock when hvm_mmio_internal() is called from
+ * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
+ */
+if ( (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
+ (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+return 0;
+
spin_lock(s-lock);
-if ( !s-stdvga ||
- (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
- (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+if ( !s-stdvga )
goto reject;
if ( p-dir == IOREQ_WRITE p-count 1 )
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 11/17] xen/arm: ITS: Add GICR register emulation
On Sat, 2015-07-11 at 20:25 +0200, Julien Grall wrote:
Hi,
On 10/07/2015 17:10, Ian Campbell wrote:
Extra space after the .
@@ -694,6 +755,14 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v,
mmio_info_t *info)
*r = ((ncpus - 1) GICD_TYPE_CPUS_SHIFT |
DIV_ROUND_UP(v-domain-arch.vgic.nr_spis, 32));
+if ( gic_lpi_supported() )
+{
+irq_bits = gic_nr_id_bits();
+*r |= GICD_TYPE_LPIS;
+}
+else
+irq_bits = get_count_order(vgic_num_irqs(v-domain));
I think gic_nr_id_bits should return the correct thing whether or not
LPIs are supported, i.e.
if ( gic_lpi_supported() )
*r |= GICD_TYPE_LPIS;
irq_bits = gic_nr_id_bits();
should be sufficient.
Well no. The field GICD_TYPER.IDbits represents the number of bits
supported for the interrupt identifier.
The guest may have a different number of IDbits than the hardware which
could be higher (for instance a guest where emulated SPI is supported).
Yes, I really meant vgic_nr_id_bits(), which might for the dom0 case end
up returning something related to the h/w value from the appropriate
vgic hw cfg struct.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 13.07.15 at 11:05, paul.durr...@citrix.com wrote:
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
hvm_io_handle
{
struct hvm_hw_stdvga *s = current-domain-arch.hvm_domain.stdvga;
+/*
+ * The range check must be done without taking any locks, to avoid
+ * deadlock when hvm_mmio_internal() is called from
+ * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
+ */
+if ( (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
+ (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+return 0;
+
spin_lock(s-lock);
-if ( !s-stdvga ||
- (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
- (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+if ( !s-stdvga )
goto reject;
if ( p-dir == IOREQ_WRITE p-count 1 )
But won't the problem continue to exist if the address falls within the
VGA range? I.e. isn't the problem that the two uses of
hvm_mmio_internal() are quite different - while
hvm_hap_nested_page_fault() immediately afterwards calls a
handle_mmio() variant (which would even seem to call for the lock not
getting dropped between them), __hvm_copy() uses it as just a check.
I.e. perhaps better to convert the lock to a recursive one?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 59477: regressions - trouble: broken/fail/pass
flight 59477 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/59477/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail in 58831 REGR. vs. 30511 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken pass in 59456 test-amd64-amd64-xl-sedf-pin 6 xen-boot fail in 58831 pass in 58798 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 58798 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 58798 test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 58831 test-amd64-i386-pair 9 xen-boot/src_host fail pass in 58831 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 59456 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-xsm 3 host-install(3) broken baseline untested test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken like 30496 test-amd64-i386-libvirt 3 host-install(3) broken like 32166-bisect test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-multivcpu 6 xen-boot fail baseline untested test-amd64-amd64-xl-credit2 6 xen-bootfail baseline untested test-amd64-amd64-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-i386-xl-xsm6 xen-bootfail baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2 fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-rtds 6 xen-bootfail baseline untested test-amd64-amd64-xl-sedf 6 xen-boot fail in 58831 like 30406 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail in 58831 like 58808-bisect test-amd64-amd64-xl-xsm 6 xen-boot fail in 59456 baseline untested test-amd64-i386-libvirt 11 guest-start fail in 59456 like 30511 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 30511 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 30511 test-amd64-amd64-libvirt 11 guest-start fail like 30511 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect test-amd64-i386-xl6 xen-bootfail like 53725-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail like 58780-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail like 58786-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-bootfail like 58788-bisect test-amd64-i386-rumpuserxen-i386 6 xen-bootfail like 58799-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-bootfail like 58801-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 58803-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail like 58804-bisect test-amd64-i386-freebsd10-i386 6 xen-boot fail like 58805-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail like 58806-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail like 58807-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-bootfail like 58809-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-boot fail like 58810-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-bootfail like 58811-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail like 58813-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-bootfail like 58814-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-bootfail like 58815-bisect Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 58831 never pass test-amd64-amd64-libvirt 12 migrate-support-check fail in 58831 never pass test-amd64-i386-libvirt 12 migrate-support-check fail in 58831 never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 59456 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass version targeted for testing: linuxcf1b3dad6c5699b977273276bada8597636ef3e2 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 Last test of basis30511 2014-09-29 16:37:46 Z 286 days Failing since 32004 2014-12-02 04:10:03 Z 223 days 173 attempts Testing same since58781 2015-06-20 14:15:50 Z 22
Re: [Xen-devel] [PATCH 3/9] libxl: json string object can be NULL
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
It occurs to me that since libxl__strdup can never return NULL due to
allocation failure we could consider make libxl__strdup(gc, NULL) be
well defined as returning NULL.
---
tools/libxl/libxl_json.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 346929a..652b3f4 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -433,8 +433,13 @@ int libxl__string_parse_json(libxl__gc *gc, const
libxl__json_object *o,
if (libxl__json_object_is_null(o))
*p = NULL;
-else
-*p = libxl__strdup(NOGC, libxl__json_object_get_string(o));
+else {
+const char *s = libxl__json_object_get_string(o);
+if (!s)
+*p = NULL;
+else
+*p = libxl__strdup(NOGC, s);
+}
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 1/1] libxl: set stub domain size based on VRAM size
Ian Jackson writes (Re: [PATCH V2 1/1] libxl: set stub domain size based on VRAM size): Eric Shelton writes ([PATCH V2 1/1] libxl: set stub domain size based on VRAM size): Allocate additional memory to the stub domain for qemu-traditional if more than 4 MB is assigned to the video adapter to avoid out of memory condition for QEMU. Acked-by: Ian Jackson ian.jack...@eu.citrix.com This is IMO a bugfix so I am queueing it for 4.6. My build test failed. It turns out that max() is no good because the types of `4096' and `guest_config-b_info.video_memkb' are not the same. In a moment I am going to send a v3 which uses max_t and uint64_t (which is the type of the memkb fields and also obviously correct). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6 v3] libxl: set stub domain size based on VRAM size
From: Eric Shelton eshel...@pobox.com Allocate additional memory to the stub domain for qemu-traditional if more than 4 MB is assigned to the video adapter to avoid out of memory condition for QEMU. Signed-off-by: Eric Shelton eshel...@pobox.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com --- v3: Use max_t() instead v2: Use max() --- tools/libxl/libxl_dm.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index ad434f0..f700f9a 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1095,7 +1095,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) libxl_domain_build_info_init_type(dm_config-b_info, LIBXL_DOMAIN_TYPE_PV); dm_config-b_info.max_vcpus = 1; -dm_config-b_info.max_memkb = 32 * 1024; +dm_config-b_info.max_memkb = 28 * 1024 + +max_t(uint64_t, guest_config-b_info.video_memkb, 4096); dm_config-b_info.target_memkb = dm_config-b_info.max_memkb; dm_config-b_info.u.pv.features = ; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 04/13] toolstack: distinguish local and remote migration support
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote: @@ -23,5 +23,9 @@ use Osstest::TestSupport; tsreadconfig(); our $ho = selecthost($ARGV[0]); +# $ARGV[1] is guest name, $ARG[2] indicates whether it is checking for +# local migration or remote migration +# Mode should be either 1 (local) or 0 (remote) +our $mode = $ARGV[2]; I think: our ($whhost, $gn, $mode) = @ARGV; our $ho = selecthost($whhost); would be preferable to the first two lines of the comment. -exit(toolstack($ho)-migrate_check()); +exit(toolstack($ho)-migrate_check($mode)); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 RFC 0/6] x86/MSI: XSA-120, 126, 128-131 follow-up
On 22.06.15 at 16:38, jbeul...@suse.com wrote:
Only patches 1, 2, and 6 are really RFC (with some debugging code still
left in), the others (hence v4) have been submitted before.
1: PCI: add config space write abstract intercept logic
2: MSI-X: track host and guest mask-all requests separately
3: MSI-X: be more careful during teardown
4: MSI-X: access MSI-X table only after having enabled MSI-X
5: MSI-X: reduce fiddling with control register during restore
6: MSI: properly track guest masking requests
A fundamental question is whether to go without the so far missing
(and more involved) MMCFG intercepts. This largely depends
whether there are any half way recent Dom0 OSes using MMCFG
accesses for the base 256 bytes of PCI config space.
Below/attached a 7th patch dealing with MMCFG accesses for
devices we know about _before_ Dom0 setting up its mapping
of MMCFG space. As noted at its top, this means it still won't
work for a number of cases (not mentioned there is the case of
Dom0 re-organizing bus numbering in order to e.g. fit in SR-IOV
virtual functions).
There are two approaches I can see to deal with these cases,
neither of which I like particularly:
1) Globally intercept all MMCFG writes (i.e. independent of
whether there's anything we actually need to see, like the MSI/
MSI-X mask bits that are of interest here). The part that makes
me dislike this model is the increased involvement of the x86
instruction emulator plus the increased chances of us needing to
deal with other than just plain stores.
2) Track Dom0 mappings of MMCFG space: We'd need to set up
(if not covered by the frame table) struct page_info for all
involved pages, and either overload it to store two or three
pointers back to L1 page table slots where the respective page
is being mapped, or (if two or three mappings per page don't
suffice) attach a linked list of such pointers. I think it goes
without saying that the complexity of getting this overload
right (i.e. namely to not conflict with any existing uses) as well
as the need to not lose track of any mappings are the reasons
I'm not really keen on this one.
Models I considered and found not suitable (and can recall right
now):
3) Hunt down Dom0 mappings at the time we learn we need to
intercept writes for a particular device. The overhead of having
to scan all Dom0 page tables seems prohibitive of such a solution.
4) Initially disallow writes to MMCFG pages globally, granting
write permission upon first write access when we can determine
that the device doesn't need any snooping. This wouldn't cope
with hotplug (and alike for SR-IOV VFs), as we might end up
needing to revoke write access.
5) Mandating Dom0 to use hypervisor managed mappings of
MMCFG space. For one this would require all Dom0 kernels to be
changed. And then it wouldn't be usable for 32-bit Dom0, as
there's no VA space left to place such a mapping, and even if we
recycled some of the compat M2P space the range wouldn't be
large enough to just cover a single segment's space, not to
speak of multiple segments. And introducing a windowing model
would make Dom0 changes even more complex (for little benefit,
considering that generally we'd expect most people to use 64-bit
kernels these days).
6) Mandating at least config space writes to be done via hypercall.
This again would require all Dom0 kernels to change.
Hence - if anyone has any better idea, please speak up soon. And
of course also if anyone has a particular preference between the
two presented viable options.
Jan
TODO: currently dependent upon IOMMU being enabled (due to bus scan only
happening in that case)
TODO: SR-IOV (and alike?) devices not visible at time of MMCFG registration
TODO: remove //temp-s
--- unstable.orig/xen/arch/x86/mm.c
+++ unstable/xen/arch/x86/mm.c
@@ -5208,6 +5208,7 @@ int ptwr_do_page_fault(struct vcpu *v, u
/* We are looking only for read-only mappings of p.t. pages. */
if ( ((l1e_get_flags(pte) (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) ||
+ rangeset_contains_singleton(mmio_ro_ranges, l1e_get_pfn(pte)) ||
!get_page_from_pagenr(l1e_get_pfn(pte), d) )
goto bail;
@@ -5255,6 +5256,7 @@ int ptwr_do_page_fault(struct vcpu *v, u
struct mmio_ro_emulate_ctxt {
struct x86_emulate_ctxt ctxt;
unsigned long cr2;
+unsigned int seg, bdf;
};
static int mmio_ro_emulated_read(
@@ -5294,6 +5296,50 @@ static const struct x86_emulate_ops mmio
.write = mmio_ro_emulated_write,
};
+static int mmio_intercept_write(
+enum x86_segment seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+struct mmio_ro_emulate_ctxt *mmio_ctxt =
+container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
+
+/*
+ * Only allow naturally-aligned stores no wider than 4 bytes to the
+ * original %cr2 address.
+ */
+if ( ((bytes | offset) (bytes - 1)) || bytes 4 ||
+ offset !=
Re: [Xen-devel] [PATCH OSSTEST v8 2/2] mg-all-branch-statuses: Show how up to date each branch is
On Thu, 2015-07-09 at 15:30 +0100, Ian Campbell wrote: Using report_find_push_age_info allows us to provide counts of attempts since the last baseline on current tip as well as the first attempt of each of those. Since everything serialises on the repo lock I didn't bother trying to parallelise anything. It's a little terse to keep it in 80 chars. cron infrastructure is added to run this in a new $HOME/for-maintjobs.git on a daily basis and push the output to the location given in the Publish config variable, if it is set (it is set in production but not for cambridge). This is now live at: http://logs.test-lab.xenproject.org/osstest/results/all-branch-statuses.txt It includes: maintjobs Error! 0- n/an/a I'm considering giving mg-all-branch-statuses a new optional argument which if present will be a path to a directory which will be used to filter the branches by checking that a for-$branch.git directory exists there. cr-all-branch-statuses would pass $HOME/branches. What do you think? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Requesting for freeze exception for RMRR
On Mon, Jul 13, 2015 at 02:31:58PM +0800, Chen, Tiejun wrote: Hi Wei, Here I'm trying to request the freeze exception for RMRR. 1. clarify the state of patch series / feature. Reviewed Acked RMRR series v7 Y Y [v7][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map Y Y [v7][PATCH 02/16] xen/vtd: create RMRR mapping Y N [v7][PATCH 03/16] xen/passthrough: extend hypercall to support rdm reservation policy Y Y [v7][PATCH 04/16] xen: enable XENMEM_memory_map in hvm Y N [v7][PATCH 05/16] hvmloader: get guest memory map into memory_map[] Y N [v7][PATCH 06/16] hvmloader/pci: skip reserved ranges Y N [v7][PATCH 07/16] hvmloader/e820: construct guest e820 table Y Y [v7][PATCH 08/16] tools/libxc: Expose new hypercall xc_reserved_device_memory_map Y Y [v7][PATCH 09/16] tools: extend xc_assign_device() to support rdm reservation policy Y Y [v7][PATCH 10/16] tools: introduce some new parameters to set rdm policy Y Y [v7][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM Y Y [v7][PATCH 12/16] tools: introduce a new parameter to set a predefined rdm boundary Y Y [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest Y Y [v7][PATCH 14/16] xen/vtd: enable USB device assignment Y Y [v7][PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr Y Y [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters Please work with maintainers to get those hvmloader patches acked or reviewed. Note Jackson and Campbell also raised some comments to improve current codes. 2. explain why it needs to be in this release (benefits). RMRR mechanism was broken for a long time and this makes VM always face security issues. In addition, those associated devices can't be passed through to VM and even result in VM crashes. 3. explain why it doesn't break things (risks). Our policy makes sure that system will work in the original way by default as without the RMRR patches. And especially, this series just impacts those platforms which have RMRR. Your patches touch crucial path in hvmloader to build memory map. There is risk that it may break hvmloader even if it is turned off. I would need at least some positive test results from you to confirm if this feature is turned off everything works as before. Wei. 4. CC relevant maintainers and release manager. Done Cheers, Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
-Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- boun...@lists.xen.org] On Behalf Of Paul Durrant Sent: 13 July 2015 11:12 To: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:42 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:05 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:03 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)
[Xen-devel] [PATCH v3 22/28] tools/libxc+libxl+xl: Save v2 streams
This is a complicated set of changes which must be done together for
bisectability.
* libxl-save-helper is updated to unconditionally use libxc migration v2.
* libxl compatibility workarounds in libxc are disabled for save operations.
* libxl__stream_write_start() is logically spliced into the event location
where libxl__xc_domain_save() used to reside.
* Ownership of the helper state moves into stream_write_state.
* xl is updated to indicate that the stream is now v2
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Many small changes, follwing similar review to the restore side
---
tools/libxc/Makefile |2 --
tools/libxl/libxl.h |2 ++
tools/libxl/libxl_dom.c | 73 --
tools/libxl/libxl_internal.h |3 +-
tools/libxl/libxl_save_helper.c |2 +-
tools/libxl/libxl_stream_write.c | 39 +---
tools/libxl/xl_cmdimpl.c |1 +
7 files changed, 63 insertions(+), 59 deletions(-)
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 2cd0b1a..1aec848 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -64,8 +64,6 @@ GUEST_SRCS-$(CONFIG_X86) += xc_sr_save_x86_hvm.c
GUEST_SRCS-y += xc_sr_restore.c
GUEST_SRCS-y += xc_sr_save.c
GUEST_SRCS-y += xc_offline_page.c xc_compression.c
-xc_sr_save_x86_hvm.o: CFLAGS += -DXG_LIBXL_HVM_COMPAT
-xc_sr_save_x86_hvm.opic: CFLAGS += -DXG_LIBXL_HVM_COMPAT
else
GUEST_SRCS-y += xc_nomigrate.c
endif
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 74b0829..5a7308d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -812,6 +812,8 @@
*
* If this is defined, then the libxl_domain_create_restore() interface takes
* a stream_version parameter and supports a value of 2.
+ *
+ * libxl_domain_suspend() will produce a v2 stream.
*/
#define LIBXL_HAVE_SRM_V2 1
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 9719837..0794b30 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1153,6 +1153,8 @@ int libxl__toolstack_restore(uint32_t domid, const
uint8_t *ptr,
/* Domain suspend (save) */
+static void stream_done(libxl__egc *egc,
+libxl__stream_write_state *sws, int rc);
static void domain_suspend_done(libxl__egc *egc,
libxl__domain_suspend_state *dss, int rc);
static void domain_suspend_callback_common_done(libxl__egc *egc,
@@ -1379,7 +1381,7 @@ static void switch_logdirty_done(libxl__egc *egc,
} else {
broke = 0;
}
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, broke);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs,
broke);
}
/*- callbacks, called by xc_domain_save -*/
@@ -1842,7 +1844,7 @@ static void
domain_suspend_callback_common_done(libxl__egc *egc,
libxl__domain_suspend_state *dss, int rc)
{
dss-rc = rc;
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, !rc);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, !rc);
}
/*- remus callbacks -*/
@@ -1878,7 +1880,7 @@ static void
remus_domain_suspend_callback_common_done(libxl__egc *egc,
out:
dss-rc = rc;
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, !rc);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, !rc);
}
static void remus_devices_postsuspend_cb(libxl__egc *egc,
@@ -1895,7 +1897,7 @@ static void remus_devices_postsuspend_cb(libxl__egc *egc,
out:
if (rc)
dss-rc = rc;
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, !rc);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, !rc);
}
static void libxl__remus_domain_resume_callback(void *data)
@@ -1930,7 +1932,7 @@ static void remus_devices_preresume_cb(libxl__egc *egc,
out:
if (rc)
dss-rc = rc;
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, !rc);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, !rc);
}
/*- remus asynchronous checkpoint callback -*/
@@ -1978,7 +1980,7 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc,
return;
out:
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, 0);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, 0);
}
static void remus_devices_commit_cb(libxl__egc *egc,
@@ -2013,7 +2015,7 @@ static void remus_devices_commit_cb(libxl__egc *egc,
return;
out:
-libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, 0);
+libxl__xc_domain_saverestore_async_callback_done(egc, dss-sws.shs, 0);
}
static void remus_next_checkpoint(libxl__egc *egc, libxl__ev_time *ev,
@@ -2034,7 +2036,7 @@ static void
[Xen-devel] [PATCH v3 27/28] tools/libxc: Drop all XG_LIBXL_HVM_COMPAT code from libxc
Libxl has now been fully adjusted not to need it.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxc/xc_sr_common.h |5 --
tools/libxc/xc_sr_restore.c | 18 -
tools/libxc/xc_sr_restore_x86_hvm.c | 124 ---
tools/libxc/xc_sr_save_x86_hvm.c| 36 --
4 files changed, 183 deletions(-)
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 1f4d4e4..64f6082 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -309,11 +309,6 @@ struct xc_sr_context
/* HVM context blob. */
void *context;
size_t contextsz;
-
-/* #ifdef XG_LIBXL_HVM_COMPAT */
-uint32_t qlen;
-void *qbuf;
-/* #endif */
} restore;
};
} x86_hvm;
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 18ba411..bf1ee15 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -627,9 +627,6 @@ static void cleanup(struct xc_sr_context *ctx)
PERROR(Failed to clean up);
}
-#ifdef XG_LIBXL_HVM_COMPAT
-extern int read_qemu(struct xc_sr_context *ctx);
-#endif
/*
* Restore a domain.
*/
@@ -656,21 +653,6 @@ static int restore(struct xc_sr_context *ctx)
goto err;
}
-#ifdef XG_LIBXL_HVM_COMPAT
-if ( ctx-dominfo.hvm
- (rec.type == REC_TYPE_END || rec.type == REC_TYPE_CHECKPOINT) )
-{
-rc = read_qemu(ctx);
-if ( rc )
-{
-if ( ctx-restore.buffer_all_records )
-goto remus_failover;
-else
-goto err;
-}
-}
-#endif
-
if ( ctx-restore.buffer_all_records
rec.type != REC_TYPE_END
rec.type != REC_TYPE_CHECKPOINT )
diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c
b/tools/libxc/xc_sr_restore_x86_hvm.c
index 6f5af0e..49d22c7 100644
--- a/tools/libxc/xc_sr_restore_x86_hvm.c
+++ b/tools/libxc/xc_sr_restore_x86_hvm.c
@@ -3,24 +3,6 @@
#include xc_sr_common_x86.h
-#ifdef XG_LIBXL_HVM_COMPAT
-static int handle_toolstack(struct xc_sr_context *ctx, struct xc_sr_record
*rec)
-{
-xc_interface *xch = ctx-xch;
-int rc;
-
-if ( !ctx-restore.callbacks || !ctx-restore.callbacks-toolstack_restore
)
-return 0;
-
-rc = ctx-restore.callbacks-toolstack_restore(
-ctx-domid, rec-data, rec-length, ctx-restore.callbacks-data);
-
-if ( rc 0 )
-PERROR(restoring toolstack);
-return rc;
-}
-#endif
-
/*
* Process an HVM_CONTEXT record from the stream.
*/
@@ -93,98 +75,6 @@ static int handle_hvm_params(struct xc_sr_context *ctx,
return 0;
}
-#ifdef XG_LIBXL_HVM_COMPAT
-int read_qemu(struct xc_sr_context *ctx);
-int read_qemu(struct xc_sr_context *ctx)
-{
-xc_interface *xch = ctx-xch;
-char qemusig[21];
-uint32_t qlen;
-void *qbuf = NULL;
-int rc = -1;
-
-if ( read_exact(ctx-fd, qemusig, sizeof(qemusig)) )
-{
-PERROR(Error reading QEMU signature);
-goto out;
-}
-
-if ( !memcmp(qemusig, DeviceModelRecord0002, sizeof(qemusig)) )
-{
-if ( read_exact(ctx-fd, qlen, sizeof(qlen)) )
-{
-PERROR(Error reading QEMU record length);
-goto out;
-}
-
-qbuf = malloc(qlen);
-if ( !qbuf )
-{
-PERROR(no memory for device model state);
-goto out;
-}
-
-if ( read_exact(ctx-fd, qbuf, qlen) )
-{
-PERROR(Error reading device model state);
-goto out;
-}
-}
-else
-{
-ERROR(Invalid device model state signature '%*.*s',
- (int)sizeof(qemusig), (int)sizeof(qemusig), qemusig);
-goto out;
-}
-
-/* With Remus, this could be read many times */
-if ( ctx-x86_hvm.restore.qbuf )
-free(ctx-x86_hvm.restore.qbuf);
-ctx-x86_hvm.restore.qbuf = qbuf;
-ctx-x86_hvm.restore.qlen = qlen;
-rc = 0;
-
-out:
-if (rc)
-free(qbuf);
-return rc;
-}
-
-static int handle_qemu(struct xc_sr_context *ctx)
-{
-xc_interface *xch = ctx-xch;
-char path[256];
-uint32_t qlen = ctx-x86_hvm.restore.qlen;
-void *qbuf = ctx-x86_hvm.restore.qbuf;
-int rc = -1;
-FILE *fp = NULL;
-
-sprintf(path, XC_DEVICE_MODEL_RESTORE_FILE.%u, ctx-domid);
-fp = fopen(path, wb);
-if ( !fp )
-{
-PERROR(Failed to open '%s' for writing, path);
-goto out;
-}
-
-DPRINTF(Writing %u bytes of QEMU data, qlen);
-if ( fwrite(qbuf, 1, qlen, fp) != qlen )
-{
-PERROR(Failed to write %u bytes of QEMU data, qlen);
-goto out;
-}
-
-rc = 0;
-
- out:
-if ( fp )
-fclose(fp);
[Xen-devel] [PATCH v3 20/28] tools/libxc+libxl+xl: Restore v2 streams
This is a complicated set of changes which must be done together for
bisectability.
* libxl-save-helper is updated to unconditionally use libxc migration
v2.
* libxl compatibility workarounds in libxc are disabled for restore
operations.
* libxl__stream_read_start() is logically spliced into the event
location where libxl__xc_domain_restore() used to reside.
* Ownership of the save_helper_state moves to stream_read_state.
The parameters 'hvm', 'pae', and 'superpages' were previously
superfluous, and are completely unused in migration
v2. callbacks-toolstack_restore is handled via a migration v2 record
now, rather than via a callback from libxc.
NB: this change breaks Remus. Further untangling needs to happen
before Remus will function.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3:
* Simplify from v2.
* Alter the ownership of save_helper_state
v2:
* Drop legacy_width from the IDL
* Gain a LIBXL_HAVE_ to signify support of migration v2 streams
---
tools/libxc/Makefile|4 +--
tools/libxl/libxl.h | 17 +
tools/libxl/libxl_create.c | 52 ++-
tools/libxl/libxl_internal.h|3 ++-
tools/libxl/libxl_save_helper.c |2 +-
tools/libxl/libxl_stream_read.c | 35 +-
tools/libxl/libxl_types.idl |1 +
tools/libxl/xl_cmdimpl.c|7 +-
8 files changed, 81 insertions(+), 40 deletions(-)
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b659df4..2cd0b1a 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -64,8 +64,8 @@ GUEST_SRCS-$(CONFIG_X86) += xc_sr_save_x86_hvm.c
GUEST_SRCS-y += xc_sr_restore.c
GUEST_SRCS-y += xc_sr_save.c
GUEST_SRCS-y += xc_offline_page.c xc_compression.c
-$(patsubst %.c,%.o,$(GUEST_SRCS-y)): CFLAGS += -DXG_LIBXL_HVM_COMPAT
-$(patsubst %.c,%.opic,$(GUEST_SRCS-y)): CFLAGS += -DXG_LIBXL_HVM_COMPAT
+xc_sr_save_x86_hvm.o: CFLAGS += -DXG_LIBXL_HVM_COMPAT
+xc_sr_save_x86_hvm.opic: CFLAGS += -DXG_LIBXL_HVM_COMPAT
else
GUEST_SRCS-y += xc_nomigrate.c
endif
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e9d63c9..74b0829 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -807,6 +807,23 @@
*/
#define LIBXL_HAVE_SOCKET_BITMAP_ALLOC 1
+/*
+ * LIBXL_HAVE_SRM_V2
+ *
+ * If this is defined, then the libxl_domain_create_restore() interface takes
+ * a stream_version parameter and supports a value of 2.
+ */
+#define LIBXL_HAVE_SRM_V2 1
+
+/*
+ * LIBXL_HAVE_SRM_V1
+ *
+ * In the case that LIBXL_HAVE_SRM_V2 is set, LIBXL_HAVE_SRM_V1
+ * indicates that libxl_domain_create_restore() can handle a stream_version
+ * parameter of 1, and convert the stream format automatically.
+ */
+#define LIBXL_HAVE_SRM_V1 1
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 5d57bc3..f2b5ffb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -704,6 +704,10 @@ static void domcreate_attach_dtdev(libxl__egc *egc,
static void domcreate_console_available(libxl__egc *egc,
libxl__domain_create_state *dcs);
+static void domcreate_stream_done(libxl__egc *egc,
+ libxl__stream_read_state *srs,
+ int ret);
+
static void domcreate_rebuild_done(libxl__egc *egc,
libxl__domain_create_state *dcs,
int ret);
@@ -933,11 +937,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
/* convenience aliases */
const uint32_t domid = dcs-guest_domid;
libxl_domain_config *const d_config = dcs-guest_config;
-libxl_domain_build_info *const info = d_config-b_info;
const int restore_fd = dcs-restore_fd;
libxl__domain_build_state *const state = dcs-build_state;
-libxl__srm_restore_autogen_callbacks *const callbacks =
-dcs-shs.callbacks.restore.a;
if (rc) {
domcreate_rebuild_done(egc, dcs, rc);
@@ -970,31 +971,19 @@ static void domcreate_bootloader_done(libxl__egc *egc,
if (rc)
goto out;
-/* read signature */
-int hvm, pae, superpages;
-switch (info-type) {
-case LIBXL_DOMAIN_TYPE_HVM:
-hvm = 1;
-superpages = 1;
-pae = libxl_defbool_val(info-u.hvm.pae);
-callbacks-toolstack_restore = libxl__toolstack_restore;
-break;
-case LIBXL_DOMAIN_TYPE_PV:
-hvm = 0;
-superpages = 0;
-pae = 1;
-break;
-default:
-rc = ERROR_INVAL;
-goto out;
-}
-libxl__save_helper_init(dcs-shs);
-libxl__xc_domain_restore(egc, dcs, dcs-shs,
- hvm,
[Xen-devel] [PATCH v3 15/28] tools/python: Conversion utility for legacy migration streams
This utility will take a legacy stream as in input, and produce a v2 stream as an output. It is exec()'d by libxl to provide backwards compatibility. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- tools/python/Makefile |4 + tools/python/scripts/convert-legacy-stream | 678 2 files changed, 682 insertions(+) create mode 100755 tools/python/scripts/convert-legacy-stream diff --git a/tools/python/Makefile b/tools/python/Makefile index e933be8..df942a7 100644 --- a/tools/python/Makefile +++ b/tools/python/Makefile @@ -17,9 +17,13 @@ build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ .PHONY: install install: + $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR) + CC=$(CC) CFLAGS=$(PY_CFLAGS) $(PYTHON) setup.py install \ $(PYTHON_PREFIX_ARG) --root=$(DESTDIR) --force + $(INSTALL_PROG) scripts/convert-legacy-stream $(DESTDIR)$(PRIVATE_BINDIR) + .PHONY: test test: export LD_LIBRARY_PATH=$$(readlink -f ../libxc):$$(readlink -f ../xenstore); $(PYTHON) test.py -b -u diff --git a/tools/python/scripts/convert-legacy-stream b/tools/python/scripts/convert-legacy-stream new file mode 100755 index 000..d54fa22 --- /dev/null +++ b/tools/python/scripts/convert-legacy-stream @@ -0,0 +1,678 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- + + +Convert a legacy migration stream to a v2 stream. + + +import sys +import os, os.path +import syslog +import traceback + +from struct import calcsize, unpack, pack + +from xen.migration import legacy, public, libxc, libxl, xl + +__version__ = 1 + +fin = None # Input file/fd +fout = None# Output file/fd +twidth = 0 # Legacy toolstack bitness (32 or 64) +pv = None # Boolean (pv or hvm) +qemu = True# Boolean - process qemu record? +log_to_syslog = False # Boolean - Log to syslog instead of stdout/err? +verbose = False# Boolean - Summarise stream contents + +def stream_read(_ = None): +Read from the input +return fin.read(_) + +def stream_write(_): +Write to the output +return fout.write(_) + +def info(msg): +Info message, routed to appropriate destination +if verbose: +if log_to_syslog: +for line in msg.split(\n): +syslog.syslog(syslog.LOG_INFO, line) +else: +print msg + +def err(msg): +Error message, routed to appropriate destination +if log_to_syslog: +for line in msg.split(\n): +syslog.syslog(syslog.LOG_ERR, line) +print sys.stderr, msg + +class StreamError(StandardError): +Error with the incoming migration stream +pass + +class VM(object): +Container of VM parameters + +def __init__(self, fmt): +# Common +self.p2m_size = 0 + +# PV +self.max_vcpu_id = 0 +self.online_vcpu_map = [] +self.width = 0 +self.levels = 0 +self.basic_len = 0 +self.extd = False +self.xsave_len = 0 + +# libxl +self.libxl = fmt == libxl +self.xenstore = [] # Deferred toolstack records + +def write_libxc_ihdr(): +stream_write(pack(libxc.IHDR_FORMAT, + libxc.IHDR_MARKER, # Marker + libxc.IHDR_IDENT, # Ident + libxc.IHDR_VERSION, # Version + libxc.IHDR_OPT_LE, # Options + 0, 0)) # Reserved + +def write_libxc_dhdr(): +if pv: +dtype = libxc.DHDR_TYPE_x86_pv +else: +dtype = libxc.DHDR_TYPE_x86_hvm + +stream_write(pack(libxc.DHDR_FORMAT, + dtype,# Type + 12, # Page size + 0,# Reserved + 0,# Xen major (converted) + __version__)) # Xen minor (converted) + +def write_libxl_hdr(): +stream_write(pack(libxl.HDR_FORMAT, + libxl.HDR_IDENT, # Ident + libxl.HDR_VERSION, # Version 2 + libxl.HDR_OPT_LE | # Options + libxl.HDR_OPT_LEGACY # Little Endian and Legacy + )) + +def write_record(rt, *argl): +alldata = ''.join(argl) +length = len(alldata) + +record = pack(libxc.RH_FORMAT, rt, length) + alldata +plen = (8 - (length 7)) 7 +record += '\x00' * plen + +stream_write(record) + +def write_libxc_pv_info(vm): +write_record(libxc.REC_TYPE_x86_pv_info, + pack(libxc.X86_PV_INFO_FORMAT, + vm.width, vm.levels, 0, 0)) + +def write_libxc_pv_p2m_frames(vm, pfns): +write_record(libxc.REC_TYPE_x86_pv_p2m_frames, + pack(libxc.X86_PV_P2M_FRAMES_FORMAT, + 0, vm.p2m_size - 1), +
[Xen-devel] [PATCH v3 16/28] tools/libxl: Migration v2 stream format
From: Ross Lagerwall ross.lagerw...@citrix.com
C structures describing the Libxl migration v2 stream format
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v2: Move into libxl__ namespace
---
tools/libxl/libxl_sr_stream_format.h | 57 ++
1 file changed, 57 insertions(+)
create mode 100644 tools/libxl/libxl_sr_stream_format.h
diff --git a/tools/libxl/libxl_sr_stream_format.h
b/tools/libxl/libxl_sr_stream_format.h
new file mode 100644
index 000..f4f790b
--- /dev/null
+++ b/tools/libxl/libxl_sr_stream_format.h
@@ -0,0 +1,57 @@
+#ifndef LIBXL__SR_STREAM_FORMAT_H
+#define LIBXL__SR_STREAM_FORMAT_H
+
+/*
+ * C structures for the Migration v2 stream format.
+ * See docs/specs/libxl-migration-stream.pandoc
+ */
+
+#include stdint.h
+
+typedef struct libxl__sr_hdr
+{
+uint64_t ident;
+uint32_t version;
+uint32_t options;
+} libxl__sr_hdr;
+
+#define RESTORE_STREAM_IDENT 0x4c6962786c466d74UL
+#define RESTORE_STREAM_VERSION 0x0002U
+
+#define RESTORE_OPT_BIG_ENDIAN (1u 0)
+#define RESTORE_OPT_LEGACY (1u 1)
+
+
+typedef struct libxl__sr_rec_hdr
+{
+uint32_t type;
+uint32_t length;
+} libxl__sr_rec_hdr;
+
+/* All records must be aligned up to an 8 octet boundary */
+#define REC_ALIGN_ORDER 3U
+
+#define REC_TYPE_END 0xU
+#define REC_TYPE_LIBXC_CONTEXT 0x0001U
+#define REC_TYPE_XENSTORE_DATA 0x0002U
+#define REC_TYPE_EMULATOR_CONTEXT0x0003U
+
+typedef struct libxl__sr_emulator_hdr
+{
+uint32_t id;
+uint32_t index;
+} libxl__sr_emulator_hdr;
+
+#define EMULATOR_UNKNOWN 0xU
+#define EMULATOR_QEMU_TRADITIONAL0x0001U
+#define EMULATOR_QEMU_UPSTREAM 0x0002U
+
+#endif /* LIBXL__SR_STREAM_FORMAT_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 18/28] tools/libxl: Infrastructure to convert a legacy stream
Provide a thin wrapper around exec()ing the python conversion utility,
and a stub implementation for cases where conversion is not wanted
(i.e. not x86).
One complication is that the caller of this interface needs to assume
ownership of the output fd, to prevent it being closed while still in
use in a datacopier.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Trimmed down massively from v2, provide libxl_no_convert_callout.c
---
tools/libxl/Makefile |6 ++
tools/libxl/libxl_convert_callout.c| 158
tools/libxl/libxl_internal.h | 32 +++
tools/libxl/libxl_no_convert_callout.c | 35 +++
4 files changed, 231 insertions(+)
create mode 100644 tools/libxl/libxl_convert_callout.c
create mode 100644 tools/libxl/libxl_no_convert_callout.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index c71c5fe..68fe1c1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -56,6 +56,12 @@ else
LIBXL_OBJS-y += libxl_nonetbuffer.o
endif
+ifeq ($(CONFIG_X86),y)
+LIBXL_OBJS-y += libxl_convert_callout.o
+else
+LIBXL_OBJS-y += libxl_no_convert_callout.o
+endif
+
LIBXL_OBJS-y += libxl_remus_device.o libxl_remus_disk_drbd.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
diff --git a/tools/libxl/libxl_convert_callout.c
b/tools/libxl/libxl_convert_callout.c
new file mode 100644
index 000..f5d99f1
--- /dev/null
+++ b/tools/libxl/libxl_convert_callout.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (C) 2014 Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include libxl_osdeps.h
+
+#include libxl_internal.h
+
+/*
+ * Infrastructure for converting a legacy migration stream into a
+ * libxl v2 stream.
+ *
+ * This is done by fork()ing the python conversion script, which takes
+ * in a legacy stream, and puts out a suitably-formatted v2 stream.
+ */
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+ pid_t pid, int status);
+static void helper_stop(libxl__egc *egc, libxl__ao_abortable *abrt, int rc);
+static void helper_done(libxl__egc *egc,
+libxl__conversion_helper_state *chs);
+
+/*- Entrypoints -*/
+
+void libxl__conversion_helper_init(libxl__conversion_helper_state *chs)
+{
+libxl__ao_abortable_init(chs-abrt);
+libxl__ev_child_init(chs-child);
+}
+
+int libxl__convert_legacy_stream(libxl__egc *egc,
+ libxl__conversion_helper_state *chs)
+{
+STATE_AO_GC(chs-ao);
+libxl__carefd *child_in = NULL, *child_out = NULL;
+int rc = 0;
+
+chs-abrt.ao = chs-ao;
+chs-abrt.callback = helper_stop;
+rc = libxl__ao_abortable_register(chs-abrt);
+if (rc) goto err;
+
+libxl__carefd_begin();
+int fds[2];
+if (libxl_pipe(CTX, fds)) {
+rc = ERROR_FAIL;
+libxl__carefd_unlock();
+goto err;
+}
+child_out = libxl__carefd_record(CTX, fds[0]);
+child_in = libxl__carefd_record(CTX, fds[1]);
+libxl__carefd_unlock();
+
+pid_t pid = libxl__ev_child_fork(gc, chs-child, helper_exited);
+if (!pid) {
+char * const args[] =
+{
+getenv(LIBXL_CONVERT_HELPER) ?:
+LIBEXEC_BIN /convert-legacy-stream,
+--in, GCSPRINTF(%d, chs-legacy_fd),
+--out,GCSPRINTF(%d, fds[1]),
+--width,
+#ifdef __i386__
+32,
+#else
+64,
+#endif
+--guest, chs-hvm ? hvm : pv,
+--format, libxl,
+/* --verbose, */
+NULL,
+};
+
+libxl_fd_set_cloexec(CTX, chs-legacy_fd, 0);
+libxl_fd_set_cloexec(CTX, libxl__carefd_fd(child_in), 0);
+
+libxl__exec(gc,
+-1, -1, -1,
+args[0], args, NULL);
+}
+
+libxl__carefd_close(child_in);
+chs-v2_carefd = child_out;
+
+assert(!rc);
+return rc;
+
+ err:
+libxl__ao_abortable_deregister(chs-abrt);
+assert(rc);
+return rc;
+}
+
+void libxl__conversion_helper_abort(libxl__egc *egc,
+libxl__conversion_helper_state *chs,
+int rc)
+{
+STATE_AO_GC(chs-ao);
+assert(rc);
+
+if (libxl__conversion_helper_inuse(chs)) {
+
+if (!chs-rc)
+chs-rc = rc;
+
+
[Xen-devel] [PATCH v3 25/28] tools/libx{c, l}: Introduce restore_callbacks.checkpoint()
And call it when a checkpoint record is found in the libxc stream.
Some parts of this patch have been based on patches from the COLO
series.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Named constants for the API
v2: Borrow sufficient fragments from several COLO patches to get
BROKEN_CHANNEL and checkpoint failover to function.
---
tools/libxc/include/xenguest.h |7 +
tools/libxc/xc_sr_common.h |7 +++--
tools/libxc/xc_sr_restore.c| 53 ++--
tools/libxl/libxl_save_msgs_gen.pl |2 +-
4 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..e95af54 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -102,6 +102,13 @@ struct restore_callbacks {
int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
uint32_t size, void* data);
+/* A checkpoint record has been found in the stream.
+ * returns: */
+#define XGR_CHECKPOINT_ERROR0 /* Terminate processing */
+#define XGR_CHECKPOINT_SUCCESS 1 /* Continue reading more data from the
stream */
+#define XGR_CHECKPOINT_FAILOVER 2 /* Failover and resume VM */
+int (*checkpoint)(void* data);
+
/* to be provided as the last argument to each callback function */
void* data;
};
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 08c66db..1f4d4e4 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -130,10 +130,13 @@ struct xc_sr_restore_ops
* Process an individual record from the stream. The caller shall take
* care of processing common records (e.g. END, PAGE_DATA).
*
- * @return 0 for success, -1 for failure, or the sentinel value
- * RECORD_NOT_PROCESSED.
+ * @return 0 for success, -1 for failure, or the following sentinels:
+ * - RECORD_NOT_PROCESSED
+ * - BROKEN_CHANNEL: under Remus/COLO, this means master may be dead, and
+ *a failover is needed.
*/
#define RECORD_NOT_PROCESSED 1
+#define BROKEN_CHANNEL 2
int (*process_record)(struct xc_sr_context *ctx, struct xc_sr_record *rec);
/**
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 9e27dba..18ba411 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -1,5 +1,7 @@
#include arpa/inet.h
+#include assert.h
+
#include xc_sr_common.h
/*
@@ -472,7 +474,7 @@ static int handle_page_data(struct xc_sr_context *ctx,
struct xc_sr_record *rec)
static int handle_checkpoint(struct xc_sr_context *ctx)
{
xc_interface *xch = ctx-xch;
-int rc = 0;
+int rc = 0, ret;
unsigned i;
if ( !ctx-restore.checkpointed )
@@ -482,6 +484,21 @@ static int handle_checkpoint(struct xc_sr_context *ctx)
goto err;
}
+ret = ctx-restore.callbacks-checkpoint(ctx-restore.callbacks-data);
+switch ( ret )
+{
+case XGR_CHECKPOINT_SUCCESS:
+break;
+
+case XGR_CHECKPOINT_FAILOVER:
+rc = BROKEN_CHANNEL;
+goto err;
+
+default: /* Other fatal error */
+rc = -1;
+goto err;
+}
+
if ( ctx-restore.buffer_all_records )
{
IPRINTF(All records buffered);
@@ -560,19 +577,6 @@ static int process_record(struct xc_sr_context *ctx,
struct xc_sr_record *rec)
free(rec-data);
rec-data = NULL;
-if ( rc == RECORD_NOT_PROCESSED )
-{
-if ( rec-type REC_TYPE_OPTIONAL )
-DPRINTF(Ignoring optional record %#x (%s),
-rec-type, rec_type_to_str(rec-type));
-else
-{
-ERROR(Mandatory record %#x (%s) not handled,
- rec-type, rec_type_to_str(rec-type));
-rc = -1;
-}
-}
-
return rc;
}
@@ -678,7 +682,22 @@ static int restore(struct xc_sr_context *ctx)
else
{
rc = process_record(ctx, rec);
-if ( rc )
+if ( rc == RECORD_NOT_PROCESSED )
+{
+if ( rec.type REC_TYPE_OPTIONAL )
+DPRINTF(Ignoring optional record %#x (%s),
+rec.type, rec_type_to_str(rec.type));
+else
+{
+ERROR(Mandatory record %#x (%s) not handled,
+ rec.type, rec_type_to_str(rec.type));
+rc = -1;
+goto err;
+}
+}
+else if ( rc == BROKEN_CHANNEL )
+goto remus_failover;
+else if ( rc )
goto err;
}
@@ -735,6 +754,10 @@ int xc_domain_restore2(xc_interface *xch, int io_fd,
uint32_t dom,
[Xen-devel] [PATCH v3 12/28] tools/python: Libxl migration v2 infrastructure
Contains:
* Python implementation of the libxl migration v2 records
* Verification code for spec compliance
* Unit tests
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/python/xen/migration/libxl.py | 188 +++
tools/python/xen/migration/tests.py | 13 +++
2 files changed, 201 insertions(+)
create mode 100644 tools/python/xen/migration/libxl.py
diff --git a/tools/python/xen/migration/libxl.py
b/tools/python/xen/migration/libxl.py
new file mode 100644
index 000..4e1f4f8
--- /dev/null
+++ b/tools/python/xen/migration/libxl.py
@@ -0,0 +1,188 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+
+Libxl Migration v2 streams
+
+Record structures as per docs/specs/libxl-migration-stream.pandoc, and
+verification routines.
+
+
+import sys
+
+from struct import calcsize, unpack
+from xen.migration.verify import StreamError, RecordError, VerifyBase
+from xen.migration.libxc import VerifyLibxc
+
+# Header
+HDR_FORMAT = !QII
+
+HDR_IDENT = 0x4c6962786c466d74 # LibxlFmt in ASCII
+HDR_VERSION = 2
+
+HDR_OPT_BIT_ENDIAN = 0
+HDR_OPT_BIT_LEGACY = 1
+
+HDR_OPT_LE = (0 HDR_OPT_BIT_ENDIAN)
+HDR_OPT_BE = (1 HDR_OPT_BIT_ENDIAN)
+HDR_OPT_LEGACY = (1 HDR_OPT_BIT_LEGACY)
+
+HDR_OPT_RESZ_MASK = 0xfffc
+
+# Records
+RH_FORMAT = II
+
+REC_TYPE_end = 0x
+REC_TYPE_libxc_context= 0x0001
+REC_TYPE_xenstore_data= 0x0002
+REC_TYPE_emulator_context = 0x0003
+
+rec_type_to_str = {
+REC_TYPE_end : End,
+REC_TYPE_libxc_context: Libxc context,
+REC_TYPE_xenstore_data: Xenstore data,
+REC_TYPE_emulator_context : Emulator context,
+}
+
+# emulator_context
+EMULATOR_CONTEXT_FORMAT = II
+
+EMULATOR_ID_unknown = 0x
+EMULATOR_ID_qemu_trad = 0x0001
+EMULATOR_ID_qemu_upstream = 0x0002
+
+emulator_id_to_str = {
+EMULATOR_ID_unknown : Unknown,
+EMULATOR_ID_qemu_trad : Qemu Traditional,
+EMULATOR_ID_qemu_upstream : Qemu Upstream,
+}
+
+
+#
+# libxl format
+#
+
+LIBXL_QEMU_SIGNATURE = DeviceModelRecord0002
+LIBXL_QEMU_RECORD_HDR = =%dsI % (len(LIBXL_QEMU_SIGNATURE), )
+
+class VerifyLibxl(VerifyBase):
+ Verify a Libxl v2 stream
+
+def __init__(self, info, read):
+VerifyBase.__init__(self, info, read)
+
+
+def verify(self):
+ Verity a libxl stream
+
+self.verify_hdr()
+
+while self.verify_record() != REC_TYPE_end:
+pass
+
+
+def verify_hdr(self):
+ Verify a Header
+ident, version, options = self.unpack_exact(HDR_FORMAT)
+
+if ident != HDR_IDENT:
+raise StreamError(Bad image id: Expected 0x%x, got 0x%x
+ % (HDR_IDENT, ident))
+
+if version != HDR_VERSION:
+raise StreamError(Unknown image version: Expected %d, got %d
+ % (HDR_VERSION, version))
+
+if options HDR_OPT_RESZ_MASK:
+raise StreamError(Reserved bits set in image options field: 0x%x
+ % (options HDR_OPT_RESZ_MASK))
+
+if ( (sys.byteorder == little) and
+ ((options HDR_OPT_BIT_ENDIAN) != HDR_OPT_LE) ):
+raise StreamError(
+Stream is not native endianess - unable to validate)
+
+endian = [little, big][options HDR_OPT_LE]
+
+if options HDR_OPT_LEGACY:
+self.info(Libxl Header: %s endian, legacy converted % (endian, ))
+else:
+self.info(Libxl Header: %s endian % (endian, ))
+
+
+def verify_record(self):
+ Verify an individual record
+rtype, length = self.unpack_exact(RH_FORMAT)
+
+if rtype not in rec_type_to_str:
+raise StreamError(Unrecognised record type %x % (rtype, ))
+
+self.info(Libxl Record: %s, length %d
+ % (rec_type_to_str[rtype], length))
+
+contentsz = (length + 7) ~7
+content = self.rdexact(contentsz)
+
+padding = content[length:]
+if padding != \x00 * len(padding):
+raise StreamError(Padding containing non0 bytes found)
+
+if rtype not in record_verifiers:
+raise RuntimeError(No verification function for libxl record '%s'
+ % rec_type_to_str[rtype])
+else:
+record_verifiers[rtype](self, content[:length])
+
+return rtype
+
+
+def verify_record_end(self, content):
+ End record
+
+if len(content) != 0:
+raise RecordError(End record with non-zero length)
+
+
+def verify_record_libxc_context(self, content):
+ Libxc context record
+
+if len(content) != 0:
+raise RecordError(Libxc context record with non-zero length)
+
+# Verify the libxc stream, as we can't seek forwards through it
+
[Xen-devel] [PATCH v2 0/3] arm64: Add multiboot support (via fdt) for Xen boot
From: Fu Wei fu@linaro.org - This adds support for the Xen boot on ARM specification for arm64. - The implementation for Xen is following Multiboot on ARM Specification: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot and xen/docs/misc/arm/device-tree/booting.txt in Xen source code. - The multiboot/module commands have existed, so we use xen_hypervisor/xen_module instead. - This Xen boot support is built into linux module for aarch64, and can not be used alone. - Adding this functionality to the existing linux module is for reusing the existing code of devicetree. - Add the support of xen_hypervisor/xen_module commands in util/grub.d/20_linux_xen.in - Add the introduction of xen_hypervisor/xen_module commands in docs/grub.texi - The example of this support is How to boot Xen with GRUB on AArch64 the Foundation FVP model https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB Changelog: v2: remove the patches which have been accepted. according to Vladimir's suggestion, change the command manes and relevant code: multiboot--xen_hypervisor module--xen_module improve the option parsing support for xen_hypervisor/xen_module commands. add a patch for adding xen_hypervisor/xen_module support in util/grub.d/20_linux_xen.in. update docs/grub.texi patch for the new command names. v1: The first version upstream patchset to grub-devel mailing list Fu Wei (3): arm64: Add Xen boot support file * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 arm64: Add the introduction of xen_hypervisor/xen_module command in docs/grub.texi docs/grub.texi| 27 ++ grub-core/Makefile.core.def | 1 + grub-core/loader/arm64/linux.c| 6 + grub-core/loader/arm64/xen_boot.c | 615 ++ include/grub/arm64/xen_boot.h | 115 +++ util/grub.d/20_linux_xen.in | 14 +- 6 files changed, 775 insertions(+), 3 deletions(-) create mode 100644 grub-core/loader/arm64/xen_boot.c create mode 100644 include/grub/arm64/xen_boot.h -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: avoid invalid phys_proc_id reference
On 13.07.15 at 05:36, chao.p.p...@linux.intel.com wrote: phys_proc_id is invalidated in remove_siblinginfo() which gets called before cpu_smpboot_free(). This means calling cpu_to_socket(cpu) in cpu_smpboot_free() is not possible to be correct. This patch invokes remove_siblinginfo() in cpu_smpboot_free(), immediately after the use for cpu_to_socket(cpu). You having picked that variant of the two I proposed, did you verify that (as I said when talking about the alternative) there are no hidden dependencies? If you didn't, or if for whatever else reason there is any doubt, the less intrusive variant should be chosen at least for now. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] util/grub.d/20_linux_xen.in: Add arm64 support
From: Fu Wei fu@linaro.org
This patch adds the support of boot command on arm64 for XEN:
xen_hypervisor
xen_module
Signed-off-by: Fu Wei fu@linaro.org
---
util/grub.d/20_linux_xen.in | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index f532fb9..b52c50d 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -120,16 +120,16 @@ linux_entry ()
else
xen_rm_opts=no-real-mode edd=off
fi
- multiboot ${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
+ ${multiboot_cmd}${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
echo'$(echo $lmessage | grub_quote)'
- module ${rel_dirname}/${basename} placeholder
root=${linux_root_device_thisversion} ro ${args}
+ ${module_cmd} ${rel_dirname}/${basename} placeholder
root=${linux_root_device_thisversion} ro ${args}
EOF
if test -n ${initrd} ; then
# TRANSLATORS: ramdisk isn't identifier. Should be translated.
message=$(gettext_printf Loading initial ramdisk ...)
sed s/^/$submenu_indentation/ EOF
echo'$(echo $message | grub_quote)'
- module --nounzip ${rel_dirname}/${initrd}
+ ${module_cmd} --nounzip ${rel_dirname}/${initrd}
EOF
fi
sed s/^/$submenu_indentation/ EOF
@@ -185,6 +185,14 @@ case $machine in
*) GENKERNEL_ARCH=$machine ;;
esac
+if [ x$machine != xaarch64 ]; then
+ multiboot_cmd=multiboot
+ module_cmd=module
+else
+ multiboot_cmd=xen_hypervisor
+ module_cmd=xen_module
+fi
+
# Extra indentation to add to menu entries in a submenu. We're not in a submenu
# yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
submenu_indentation=
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 06/17] xen/arm: ITS: Add virtual ITS driver
On Sat, 2015-07-11 at 20:18 +0530, Vijay Kilari wrote:
On Fri, Jul 10, 2015 at 7:45 PM, Ian Campbell i...@xen.org wrote:
On Fri, 2015-07-10 at 13:12 +0530, vijay.kil...@gmail.com wrote:
+static int vits_entry(struct domain *d, paddr_t entry, void *addr,
+ uint32_t size, bool_t set)
+{
[...]
+}
+
+/* ITS device table helper functions */
+static int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
+ struct vdevice_table *entry, bool_t set)
+{
+uint64_t offset;
+paddr_t dt_entry;
+
+BUILD_BUG_ON(sizeof(struct vdevice_table) != 16);
+
+offset = dev_id * sizeof(struct vdevice_table);
+if ( offset d-arch.vits-dt_size )
+{
+dprintk(XENLOG_G_ERR,
+%pv: vITS: Out of range offset %ld id 0x%x size %ld\n,
+current, offset, dev_id, d-arch.vits-dt_size);
+return -EINVAL;
+}
+
+dt_entry = d-arch.vits-dt_ipa + offset;
+
+return vits_entry(d, dt_entry, (void *)entry,
+ sizeof(struct vdevice_table),
Please drop the (void *) cast here, you can pass a foo * to a void *
without one.
It took me a little while to work out why this was void * before I
realised that vits_entry was a generic helper used for different types
of table. vits_access_guest_table to make it clear what it is doing.
This is also used in later patches read virtual ITS command and also
property pending table. I prefer to move it to some generic file like
guestcopy.c/p2m.c?
and should be named as copy_{from|to}guest_gfn()?
I nearly suggested using the existing copy to/from guest functions but:
Why do the existing copy to/from guest helpers not check the page has
memory type. If it did they would be closer to being directly usable.
Those functions check for guest read/write access as appropriate, but
those do not apply to this case (which is in effect a privileged DMA
from outside the virtual CPU).
In particular due to the second thing I think we would be best off
keeping this as a specific helper for the VITS, having general helper
functions with lax security checks in them just invites people to use
them inappropriately.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 06/17] xen/arm: ITS: Add virtual ITS driver
On Sat, 2015-07-11 at 20:18 +0530, Vijay Kilari wrote: Hi Ian, On Fri, Jul 10, 2015 at 7:24 PM, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2015-07-10 at 13:12 +0530, vijay.kil...@gmail.com wrote: +/* RB-tree helpers for vits_device attached to a domain */ In the rest of the series I found this used in three places: * On assignment, to insert the device into the tree * On deassignment, to remove it again * In vgic_vcpu_inject_lpi, where the device is looked up and then never used. I don't see any other use and therefore I don't think this RB tree serves any purpose, which is consistent with the design which doesn't require this lookup anywhere. Please remove it. If there is some use of it in some future series (e.g. perhaps the PCI one) then please still remove it and add a patch to that series to introduce it. You mean for now we will remove RB-tree for managing devices assigned to domain Yes, it isn't needed for ITS at all AFAICT and having it around has just tempted you into using it incorrectly during vpli injection. and introduce RB-tree and do look up when pci-passthrough is introduced?. If it is needed then yes. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] libxl: fix libxl__abs_path
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
I rather dislike subjects of the form fix $function, since it gives
very little clue to someone reading the shortlog what is going on.
In this case I think libxl: make libxl__abs_path correctly handle a
NULL argument would be an accurate description.
If s is NULL, just return NULL to avoid libxl__strdup dereferencing NULL
pointer.
Signed-off-by: Wei Liu wei.l...@citrix.com
For the change itself:
Acked-by: Ian Campbell ian.campb...@citrix.com
---
tools/libxl/libxl_internal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 42d548e..6402c1b 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -233,8 +233,8 @@ void libxl__log(libxl_ctx *ctx, xentoollog_level
msglevel, int errnoval,
char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path)
{
-if (!s || s[0] == '/')
-return libxl__strdup(gc, s);
+if (!s) return NULL;
+if (s[0] == '/') return libxl__strdup(gc, s);
return libxl__sprintf(gc, %s/%s, path, s);
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/9] libxl: dispose dominfo to avoid leaking resource
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote: Add libxl_dominfo_dispose to one return path that doesn't have it. Signed-off-by: Wei Liu wei.l...@citrix.com That return is a bit at odds with the generally correct error handling in that function, but this improves things at least a little and I can sort of see why this a slightly special case, so: Acked-by: Ian Campbell ian.campb...@citrix.com --- tools/libxl/libxl_device.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 2493972..3f8b555 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -816,6 +816,8 @@ void libxl__initiate_device_remove(libxl__egc *egc, be_path); goto out; } + +libxl_dominfo_dispose(info); return; } } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 9/9] xl: fix main_config_update
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
Don't dereference NULL.
Subject: xl: correctly handle null extra config in main_config_update
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/xl_cmdimpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index d44eb4b..631dbd1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5010,7 +5010,7 @@ int main_config_update(int argc, char **argv)
if (rc) { fprintf(stderr, Failed to read config file: %s: %s\n,
filename, strerror(errno));
free(extra_config); return ERROR_FAIL; }
-if (strlen(extra_config)) {
+if (extra_config strlen(extra_config)) {
if (config_len INT_MAX - (strlen(extra_config) + 2 + 1)) {
fprintf(stderr, Failed to attach extra configration\n);
exit(1);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 for Xen 4.6 0/4] Enable per-VCPU parameter settings for RTDS scheduler
On Sat, 2015-07-11 at 15:33 +0100, Wei Liu wrote: Hi Chong This series is marked as for 4.6, but we just hit feature freeze yesterday. Yeah, I wanted to reply myself about this, but Wei beat me... Good job as release manager, I would say. :-) Given the status of this series (missing many acks), I am sorry to say this series will have to wait until next release. Indeed. The series is starting to look good, and, Chong, you're doing a great work, especially by replying promptly to reviews, and reposting new versions very quickly. However, this series arrived a bit late in the dev cycle, and suffered from some delay in reviewing (from me as well, sorry for that), but (both) this things happen in (Open Source) software development, and we can't do much about it. Also, the original goal was to pull RTDS out of experimental, but, even with this series in, we wouldn't get to there as: - not enough testing: it entered OSSTest not so long ago, which, e.g., showed up it's failing on ARM! - not enough benchmarks/performance figures: I'd like to have the latency numbers, e.g., from cyclictest, we've spoke many times with Meng, give our official blessing at using it - the work Dagaen's doing is a rather fundamental restructuring, and it makes sense to do all the above (testing and performance evaluation) on top of the result of that for a bit, before declaring things stable and supported (or we risk disrupting that because of it, and since it's already ongoing, I'll really let him finish) So, for the following reasons (coming from the above reasoning): - the series is good, but certainly still not ready; - having the series in, would not change much wrt RTDS in 4.6 I, as the maintainer of this feature, agree with Wei that we should work toward merging this series really soon... at the beginning of 4.7 development cycle! :-D We will review this series in timely manner provided there are no other urgent matters for the release. Please keep up with your good work. Indeed. Thanks a log again to you, Meng, Dagaen, and everyone. I'll review the series ASAP. 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 RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 10/13] TestSupport: don't put kernel='hvmloader' in HVM config
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote:
Setting kernel to hvmloader is ignored in xl but not in libvirt. Libvirt
config converter will translate that then pass it to QEMU. QEMU
complains there is no kernel called hvmloader and exits.
Just remove this option. Xl is not affected and libvirt will be able to
create HVM guest.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Not sure if this affects Xend. We seem to only have one test case for
xend in 4.3.
I fear it might indeed break things for 4.3 and older with xend.
---
Osstest/TestSupport.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 66dc218..5336079 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1625,7 +1625,6 @@ sub more_prepareguest_hvm (;@) {
my $disks = join ,\t\t\n, map { '$_' } @disks;
my $cfg = END;
-kernel = 'hvmloader'
builder = 'hvm'
#
disk= [
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 14/28] tools/python: Verification utility for v2 stream spec compliance
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- This is exceedingly useful for development, but not of practical use being installed into a production dom0. --- tools/python/scripts/verify-stream-v2 | 174 + 1 file changed, 174 insertions(+) create mode 100755 tools/python/scripts/verify-stream-v2 diff --git a/tools/python/scripts/verify-stream-v2 b/tools/python/scripts/verify-stream-v2 new file mode 100755 index 000..3daf257 --- /dev/null +++ b/tools/python/scripts/verify-stream-v2 @@ -0,0 +1,174 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- + + Verify a v2 format migration stream + +import sys +import struct +import os, os.path +import syslog +import traceback + +from xen.migration.verify import StreamError, RecordError +from xen.migration.libxc import VerifyLibxc +from xen.migration.libxl import VerifyLibxl + +fin = None # Input file/fd +log_to_syslog = False # Boolean - Log to syslog instead of stdout/err? +verbose = False# Boolean - Summarise stream contents +quiet = False # Boolean - Suppress error printing + +def info(msg): +Info message, routed to appropriate destination +if not quiet and verbose: +if log_to_syslog: +for line in msg.split(\n): +syslog.syslog(syslog.LOG_INFO, line) +else: +print msg + +def err(msg): +Error message, routed to appropriate destination +if not quiet: +if log_to_syslog: +for line in msg.split(\n): +syslog.syslog(syslog.LOG_ERR, line) +print sys.stderr, msg + +def stream_read(_ = None): +Read from input +return fin.read(_) + +def rdexact(nr_bytes): +Read exactly nr_bytes from fin +_ = stream_read(nr_bytes) +if len(_) != nr_bytes: +raise IOError(Stream truncated) +return _ + +def unpack_exact(fmt): +Unpack a format from fin +sz = struct.calcsize(fmt) +return struct.unpack(fmt, rdexact(sz)) + + +def skip_xl_header(): +Skip over an xl header in the stream + +hdr = rdexact(32) +if hdr != Xen saved domain, xl format\n \0 \r: +raise StreamError(No xl header) + +_, mflags, _, optlen = unpack_exact(=) +_ = rdexact(optlen) + +info(Processed xl header) + +if mflags 2: # XL_MANDATORY_FLAG_STREAMv2 +return libxl +else: +return libxc + +def read_stream(fmt): + Read an entire stream + +try: +if fmt == xl: +fmt = skip_xl_header() + +if fmt == libxc: +VerifyLibxc(info, stream_read).verify() +else: +VerifyLibxl(info, stream_read).verify() + +except (IOError, StreamError, RecordError): +err(Stream Error:) +err(traceback.format_exc()) +return 1 + +except StandardError: +err(Script Error:) +err(traceback.format_exc()) +err(Please fix me) +return 2 + +return 0 + +def open_file_or_fd(val, mode, buffering): + +If 'val' looks like a decimal integer, open it as an fd. If not, try to +open it as a regular file. + + +fd = -1 +try: +# Does it look like an integer? +try: +fd = int(val, 10) +except ValueError: +pass + +# Try to open it... +if fd != -1: +return os.fdopen(fd, mode, buffering) +else: +return open(val, mode, buffering) + +except StandardError, e: +if fd != -1: +err(Unable to open fd %d: %s: %s % +(fd, e.__class__.__name__, e)) +else: +err(Unable to open file '%s': %s: %s % +(val, e.__class__.__name__, e)) + +raise SystemExit(2) + +def main(): + main +from optparse import OptionParser +global fin, quiet, verbose + +# Change stdout to be line-buffered. +sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 1) + +parser = OptionParser(usage = %prog [options], + description = + Verify a stream according to the v2 spec) + +# Optional options +parser.add_option(-i, --in, dest = fin, metavar = FD or FILE, + default = 0, + help = Stream to verify (defaults to stdin)) +parser.add_option(-v, --verbose, action = store_true, default = False, + help = Summarise stream contents) +parser.add_option(-q, --quiet, action = store_true, default = False, + help = Suppress all logging/errors) +parser.add_option(-f, --format, dest = format, + metavar = libxc|libxl|xl, default = libxc, + choices = [libxc, libxl, xl], + help = Format of the incoming stream (defaults to libxc)) +parser.add_option(--syslog, action =
[Xen-devel] [PATCH v3 21/28] tools/libxl: Infrastructure for writing a v2 stream
From: Ross Lagerwall ross.lagerw...@citrix.com
This contains the event machinery and state machines to write
non-checkpointed migration v2 stream (with the exception of the
xc_domain_save() handling which is spliced later in a bisectable way).
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Similar changes to the read side, following the read side review.
---
tools/libxl/Makefile |2 +-
tools/libxl/libxl_internal.h | 39
tools/libxl/libxl_stream_write.c | 425 ++
3 files changed, 465 insertions(+), 1 deletion(-)
create mode 100644 tools/libxl/libxl_stream_write.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 68fe1c1..0150ec7 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -100,7 +100,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
- libxl_stream_read.o \
+ libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 72d544a..c93f4a6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2958,6 +2958,45 @@ typedef void libxl__domain_suspend_cb(libxl__egc*,
typedef void libxl__save_device_model_cb(libxl__egc*,
libxl__domain_suspend_state*, int rc);
+/* State for writing a libxl migration v2 stream */
+typedef struct libxl__stream_write_state libxl__stream_write_state;
+typedef void (*sws_record_done_cb)(libxl__egc *egc,
+ libxl__stream_write_state *sws);
+struct libxl__stream_write_state {
+/* filled by the user */
+libxl__ao *ao;
+libxl__domain_suspend_state *dss;
+int fd;
+void (*completion_callback)(libxl__egc *egc,
+libxl__stream_write_state *sws,
+int rc);
+/* Private */
+int rc;
+bool running;
+
+/* Main stream-writing data. */
+libxl__datacopier_state dc;
+sws_record_done_cb record_done_callback;
+
+/* Only used when constructing an EMULATOR record. */
+libxl__datacopier_state emu_dc;
+libxl__carefd *emu_carefd;
+libxl__sr_rec_hdr emu_rec_hdr;
+void *emu_body;
+};
+
+_hidden void libxl__stream_write_init(libxl__stream_write_state *stream);
+_hidden void libxl__stream_write_start(libxl__egc *egc,
+ libxl__stream_write_state *stream);
+_hidden void libxl__stream_write_abort(libxl__egc *egc,
+ libxl__stream_write_state *stream,
+ int rc);
+static inline bool
+libxl__stream_write_inuse(const libxl__stream_write_state *stream)
+{
+return stream-running;
+}
+
typedef struct libxl__logdirty_switch {
const char *cmd;
const char *cmd_path;
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
new file mode 100644
index 000..2e40978
--- /dev/null
+++ b/tools/libxl/libxl_stream_write.c
@@ -0,0 +1,425 @@
+/*
+ * Copyright (C) 2015 Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include libxl_osdeps.h /* must come before any other headers */
+
+#include libxl_internal.h
+
+/*
+ * Infrastructure for writing a domain to a libxl migration v2 stream.
+ *
+ * Entry points from outside:
+ * - libxl__stream_write_start()
+ * - Start writing a stream from the start.
+ *
+ * In normal operation, there are two tasks running at once; this
+ * stream processing, and the libxl-save-helper. check_all_finished()
+ * is used to join all the tasks in both success and error cases.
+ *
+ * Nomenclature for event callbacks:
+ * - $FOO_done(): Completion callback for $FOO
+ * - write_$FOO(): Set up the datacopier to write a $FOO
+ * - $BAR_header(): A $BAR record header only
+ * - $BAR_record(): A complete
[Xen-devel] [PATCH v3 26/28] tools/libxl: Handle checkpoint records in a libxl migration v2 stream
This is the final bit of untangling for Remus.
When libxc issues a checkpoint callback, start reading and buffering
all libxl records from the stream. Once a CHECKPOINT_END record is
encountered, start processing all records.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Simplify, use named constants for API
---
tools/libxl/libxl_create.c | 25
tools/libxl/libxl_internal.h|8 +++
tools/libxl/libxl_stream_read.c | 130 +++
3 files changed, 163 insertions(+)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f2b5ffb..e42de47 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -672,6 +672,27 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
libxl_device_model_version_to_string(b_info-device_model_version));
}
+/*- remus asynchronous checkpoint callback -*/
+
+static void remus_checkpoint_stream_done(
+libxl__egc *egc, libxl__stream_read_state *srs, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
+{
+libxl__save_helper_state *shs = data;
+libxl__domain_create_state *dcs = shs-caller_state;
+libxl__egc *egc = shs-egc;
+STATE_AO_GC(dcs-ao);
+
+libxl__stream_read_start_checkpoint(egc, dcs-srs);
+}
+
+static void remus_checkpoint_stream_done(
+libxl__egc *egc, libxl__stream_read_state *stream, int rc)
+{
+libxl__xc_domain_saverestore_async_callback_done(egc, stream-shs, rc);
+}
+
/*- main domain creation -*/
/* We have a linear control flow; only one event callback is
@@ -939,6 +960,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
libxl_domain_config *const d_config = dcs-guest_config;
const int restore_fd = dcs-restore_fd;
libxl__domain_build_state *const state = dcs-build_state;
+libxl__srm_restore_autogen_callbacks *const callbacks =
+dcs-srs.shs.callbacks.restore.a;
if (rc) {
domcreate_rebuild_done(egc, dcs, rc);
@@ -966,6 +989,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
}
/* Restore */
+callbacks-checkpoint = libxl__remus_domain_checkpoint_callback;
rc = libxl__build_pre(gc, domid, d_config, state);
if (rc)
@@ -978,6 +1002,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
dcs-srs.fd = restore_fd;
dcs-srs.legacy = (dcs-restore_params.stream_version == 1);
dcs-srs.completion_callback = domcreate_stream_done;
+dcs-srs.checkpoint_callback = remus_checkpoint_stream_done;
libxl__stream_read_start(egc, dcs-srs);
return;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7540ab3..176c360 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3311,9 +3311,13 @@ struct libxl__stream_read_state {
void (*completion_callback)(libxl__egc *egc,
libxl__stream_read_state *srs,
int rc);
+void (*checkpoint_callback)(libxl__egc *egc,
+libxl__stream_read_state *srs,
+int rc);
/* Private */
int rc;
bool running;
+bool in_checkpoint;
libxl__save_helper_state shs;
libxl__conversion_helper_state chs;
@@ -3323,6 +3327,8 @@ struct libxl__stream_read_state {
LIBXL_STAILQ_HEAD(, libxl__sr_record_buf) record_queue;
enum {
SRS_PHASE_NORMAL,
+SRS_PHASE_BUFFERING,
+SRS_PHASE_UNBUFFERING,
} phase;
bool recursion_guard;
@@ -3337,6 +3343,8 @@ struct libxl__stream_read_state {
_hidden void libxl__stream_read_init(libxl__stream_read_state *stream);
_hidden void libxl__stream_read_start(libxl__egc *egc,
libxl__stream_read_state *stream);
+_hidden void libxl__stream_read_start_checkpoint(libxl__egc *egc,
+ libxl__stream_read_state
*stream);
_hidden void libxl__stream_read_abort(libxl__egc *egc,
libxl__stream_read_state *stream, int
rc);
static inline bool
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index 229108b..803ac8a 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -28,11 +28,30 @@
* All complete records are held in the record_queue before being
* processed, and all records will be processed in queue order.
*
+ * Internal states:
+ * running in_checkpoint phase
+ * Undefined -- -
+ * Idle falsefalse -
+ * Active true false normal
+ * Checkpoint(buf)true true buffering
+ * Checkpoint(unbuf) true true unbuffering
+ * Active true false
[Xen-devel] [PATCH v3 24/28] tools/libxl: Write checkpoint records into the stream
when signalled to do so by libxl__remus_domain_checkpoint_callback()
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Corrections to comments
This patch has changed substantially in v2 as a result of changes earlier in
the series. No behavioural difference from v1.
---
tools/libxl/libxl_dom.c | 18 -
tools/libxl/libxl_internal.h |7
tools/libxl/libxl_stream_write.c | 77 --
3 files changed, 89 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0794b30..98eb824 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1937,8 +1937,8 @@ static void remus_devices_preresume_cb(libxl__egc *egc,
/*- remus asynchronous checkpoint callback -*/
-static void remus_checkpoint_dm_saved(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int
rc);
+static void remus_checkpoint_stream_written(
+libxl__egc *egc, libxl__stream_write_state *sws, int rc);
static void remus_devices_commit_cb(libxl__egc *egc,
libxl__remus_devices_state *rds,
int rc);
@@ -1953,17 +1953,14 @@ static void
libxl__remus_domain_checkpoint_callback(void *data)
libxl__egc *egc = shs-egc;
STATE_AO_GC(dss-ao);
-/* This would go into tailbuf. */
-if (dss-hvm) {
-libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
-} else {
-remus_checkpoint_dm_saved(egc, dss, 0);
-}
+libxl__stream_write_start_checkpoint(egc, dss-sws);
}
-static void remus_checkpoint_dm_saved(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int rc)
+static void remus_checkpoint_stream_written(
+libxl__egc *egc, libxl__stream_write_state *sws, int rc)
{
+libxl__domain_suspend_state *dss = CONTAINER_OF(sws, *dss, sws);
+
/* Convenience aliases */
libxl__remus_devices_state *const rds = dss-rds;
@@ -2114,6 +2111,7 @@ void libxl__domain_suspend(libxl__egc *egc,
libxl__domain_suspend_state *dss)
callbacks-suspend = libxl__remus_domain_suspend_callback;
callbacks-postcopy = libxl__remus_domain_resume_callback;
callbacks-checkpoint = libxl__remus_domain_checkpoint_callback;
+dss-sws.checkpoint_callback = remus_checkpoint_stream_written;
} else
callbacks-suspend = libxl__domain_suspend_callback;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6827e9c..7540ab3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2970,9 +2970,13 @@ struct libxl__stream_write_state {
void (*completion_callback)(libxl__egc *egc,
libxl__stream_write_state *sws,
int rc);
+void (*checkpoint_callback)(libxl__egc *egc,
+libxl__stream_write_state *sws,
+int rc);
/* Private */
int rc;
bool running;
+bool in_checkpoint;
libxl__save_helper_state shs;
/* Main stream-writing data. */
@@ -2989,6 +2993,9 @@ struct libxl__stream_write_state {
_hidden void libxl__stream_write_init(libxl__stream_write_state *stream);
_hidden void libxl__stream_write_start(libxl__egc *egc,
libxl__stream_write_state *stream);
+_hidden void
+libxl__stream_write_start_checkpoint(libxl__egc *egc,
+ libxl__stream_write_state *stream);
_hidden void libxl__stream_write_abort(libxl__egc *egc,
libxl__stream_write_state *stream,
int rc);
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
index 1847ec9..ca2e95f 100644
--- a/tools/libxl/libxl_stream_write.c
+++ b/tools/libxl/libxl_stream_write.c
@@ -22,6 +22,8 @@
* Entry points from outside:
* - libxl__stream_write_start()
* - Start writing a stream from the start.
+ * - libxl__stream_write_start_checkpoint()
+ * - Write the records which form a checkpoint into a stream.
*
* In normal operation, there are two tasks running at once; this
* stream processing, and the libxl-save-helper. check_all_finished()
@@ -39,6 +41,12 @@
* - Toolstack record
* - if (hvm), Qemu record
* - End record
+ *
+ * For checkpointed stream, there is a second loop which is triggered by a
+ * save-helper checkpoint callback. It writes:
+ * - Toolstack record
+ * - if (hvm), Qemu record
+ * - Checkpoint end record
*/
/* Success/error/cleanup handling. */
@@ -48,6 +56,9 @@ static void stream_complete(libxl__egc *egc,
libxl__stream_write_state *stream, int rc);
static void
[Xen-devel] [PATCH v3 13/28] tools/python: Other migration infrastructure
Contains: * Reverse-engineered notes of the legacy format from xg_save_restore.h * Python implementation of the legacy format * Public HVM Params used in the legacy stream * XL header format Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- New in v2 - removes various many magic numbers from subsequent scripts --- tools/python/xen/migration/legacy.py | 279 ++ tools/python/xen/migration/public.py | 21 +++ tools/python/xen/migration/xl.py | 12 ++ 3 files changed, 312 insertions(+) create mode 100644 tools/python/xen/migration/legacy.py create mode 100644 tools/python/xen/migration/public.py create mode 100644 tools/python/xen/migration/xl.py diff --git a/tools/python/xen/migration/legacy.py b/tools/python/xen/migration/legacy.py new file mode 100644 index 000..2f2240a --- /dev/null +++ b/tools/python/xen/migration/legacy.py @@ -0,0 +1,279 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- + + +Libxc legacy migration streams + +Documentation and record structures for legacy migration + + + +SAVE/RESTORE/MIGRATE PROTOCOL += + +The general form of a stream of chunks is a header followed by a +body consisting of a variable number of chunks (terminated by a +chunk with type 0) followed by a trailer. + +For a rolling/checkpoint (e.g. remus) migration then the body and +trailer phases can be repeated until an external event +(e.g. failure) causes the process to terminate and commit to the +most recent complete checkpoint. + +HEADER +-- + +unsigned long: p2m_size + +extended-info (PV-only, optional): + + If first unsigned long == ~0UL then extended info is present, + otherwise unsigned long is part of p2m. Note that p2m_size above + does not include the length of the extended info. + + extended-info: + +unsigned long: signature == ~0UL +uint32_t : number of bytes remaining in extended-info + +1 or more extended-info blocks of form: +char[4] : block identifier +uint32_t : block data size +bytes: block data + +defined extended-info blocks: +vcpu : VCPU context info containing vcpu_guest_context_t. + The precise variant of the context structure + (e.g. 32 vs 64 bit) is distinguished by + the block size. +extv : Presence indicates use of extended VCPU context in + tail, data size is 0. + +p2m (PV-only): + + consists of p2m_size bytes comprising an array of xen_pfn_t sized entries. + +BODY PHASE - Format A (for live migration or Remus without compression) +-- + +A series of chunks with a common header: + int : chunk type + +If the chunk type is +ve then chunk contains guest memory data, and the +type contains the number of pages in the batch: + +unsigned long[] : PFN array, length == number of pages in batch + Each entry consists of XEN_DOMCTL_PFINFO_* + in bits 31-28 and the PFN number in bits 27-0. +page data: PAGE_SIZE bytes for each page marked present in PFN + array + +If the chunk type is -ve then chunk consists of one of a number of +metadata types. See definitions of XC_SAVE_ID_* below. + +If chunk type is 0 then body phase is complete. + + +BODY PHASE - Format B (for Remus with compression) +-- + +A series of chunks with a common header: + int : chunk type + +If the chunk type is +ve then chunk contains array of PFNs corresponding +to guest memory and type contains the number of PFNs in the batch: + +unsigned long[] : PFN array, length == number of pages in batch + Each entry consists of XEN_DOMCTL_PFINFO_* + in bits 31-28 and the PFN number in bits 27-0. + +If the chunk type is -ve then chunk consists of one of a number of +metadata types. See definitions of XC_SAVE_ID_* below. + +If the chunk type is -ve and equals XC_SAVE_ID_COMPRESSED_DATA, then the +chunk consists of compressed page data, in the following format: + +unsigned long: Size of the compressed chunk to follow +compressed data : variable length data of size indicated above. + This chunk consists of compressed page data. + The number of pages in one chunk depends on + the amount of space available in the sender's + output buffer. + +Format of compressed data: + compressed_data = deltas* + delta = marker, run* + marker = (RUNFLAG|SKIPFLAG) bitwise-or RUNLEN [1 byte marker] + RUNFLAG = 0 + SKIPFLAG= 1 7 + RUNLEN = 7-bit unsigned value indicating number of WORDS in the run + run
[Xen-devel] [PATCH v3 10/28] docs: Libxl migration v2 stream specification
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- v3: Spelling fixes --- docs/specs/libxl-migration-stream.pandoc | 205 ++ 1 file changed, 205 insertions(+) create mode 100644 docs/specs/libxl-migration-stream.pandoc diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc new file mode 100644 index 000..4192950 --- /dev/null +++ b/docs/specs/libxl-migration-stream.pandoc @@ -0,0 +1,205 @@ +% LibXenLight Domain Image Format +% Andrew Cooper andrew.coop...@citrix.com +% Draft B + +Introduction + + +For the purposes of this document, `xl` is used as a representation of any +implementer of the `libxl` API. `xl` should be considered completely +interchangeable with alternates, such as `libvirt` or `xenopsd-xl`. + +Purpose +--- + +The _domain image format_ is the context of a running domain used for +snapshots of a domain or for transferring domains between hosts during +migration. + +There are a number of problems with the domain image format used in Xen 4.5 +and earlier (the _legacy format_) + +* There is no `libxl` context information. `xl` is required to send certain + pieces of `libxl` context itself. + +* The contents of the stream is passed directly through `libxl` to `libxc`. + The legacy `libxc` format contained some information which belonged at the + `libxl` level, resulting in awkward layer violation to return the + information back to `libxl`. + +* The legacy `libxc` format was inextensible, causing inextensibility in the + legacy `libxl` handling. + +This design addresses the above points, allowing for a completely +self-contained, extensible stream with each layer responsible for its own +appropriate information. + + +Not Yet Included + + +The following features are not yet fully specified and will be +included in a future draft. + +* Remus + +* ARM + + +Overview + + +The image format consists of a _Header_, followed by 1 or more _Records_. +Each record consists of a type and length field, followed by any type-specific +data. + +\clearpage + +Header +== + +The header identifies the stream as a `libxl` stream, including the version of +this specification that it complies with. + +All fields in this header shall be in _big-endian_ byte order, regardless of +the setting of the endianness bit. + + 0 1 2 3 4 5 6 7 octet ++-+ +| ident | ++---+-+ +| version | options | ++---+-+ + + +Field Description +--- +ident 0x4c6962786c466d74 (LibxlFmt in ASCII). + +version 0x0002. The version of this specification. + +options bit 0: Endianness.0 = little-endian, 1 = big-endian. + +bit 1: Legacy Format. If set, this stream was created by + the legacy conversion tool. + +bits 2-31: Reserved. + + +The endianness shall be 0 (little-endian) for images generated on an +i386, x86_64, or arm host. + +\clearpage + + +Records +=== + +A record has a record header, type specific data and a trailing footer. If +`length` is not a multiple of 8, the body is padded with zeroes to align the +end of the record on an 8 octet boundary. + + 0 1 2 3 4 5 6 7 octet ++---+-+ +| type | body_length | ++---+---+-+ +| body... | +... +| | padding (0 to 7 octets) | ++---+-+ + + +FieldDescription +--- --- +type 0x: END + + 0x0001: LIBXC_CONTEXT + + 0x0002: XENSTORE_DATA + + 0x0003: EMULATOR_CONTEXT + + 0x0004 - 0x7FFF: Reserved for future _mandatory_ + records. + + 0x8000 - 0x: Reserved for future _optional_ + records. + +body_length Length in octets of the record body. + +body Content of the record. + +padding 0 to 7 octets of zeros to pad the whole record to a multiple + of 8 octets. + + +\clearpage + +END + + +A
[Xen-devel] [PATCH v3 19/28] tools/libxl: Convert a legacy stream if needed
For backwards compatibility, a legacy stream needs converting before
it can be read by the v2 stream logic.
This causes the v2 stream logic to need to juggle two parallel tasks.
check_all_finished() is introduced for the purpose of joining the
tasks in both success and error cases.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Simplified greatly from v2. No practical change.
---
tools/libxl/libxl_internal.h|2 ++
tools/libxl/libxl_stream_read.c | 66 ++-
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4de7349..8afff06 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3260,12 +3260,14 @@ struct libxl__stream_read_state {
libxl__ao *ao;
libxl__domain_create_state *dcs;
int fd;
+bool legacy;
void (*completion_callback)(libxl__egc *egc,
libxl__stream_read_state *srs,
int rc);
/* Private */
int rc;
bool running;
+libxl__conversion_helper_state chs;
/* Main stream-reading data. */
libxl__datacopier_state dc;
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index e70c05a..93aa479 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -73,6 +73,10 @@
*- stream_write_emulator()
*- stream_write_emulator_done()
*- stream_continue()
+ *
+ * Depending on the contents of the stream, there are likely to be several
+ * parallel tasks being managed. check_all_finished() is used to join all
+ * tasks in both success and error cases.
*/
/* Success/error/cleanup handling. */
@@ -80,6 +84,10 @@ static void stream_complete(libxl__egc *egc,
libxl__stream_read_state *stream, int rc);
static void stream_done(libxl__egc *egc,
libxl__stream_read_state *stream);
+static void conversion_done(libxl__egc *egc,
+libxl__conversion_helper_state *chs, int rc);
+static void check_all_finished(libxl__egc *egc,
+ libxl__stream_read_state *stream, int rc);
/* Event chain for first iteration, from _start(). */
static void stream_header_done(libxl__egc *egc,
@@ -138,17 +146,42 @@ void libxl__stream_read_init(libxl__stream_read_state
*stream)
{
FILLZERO(*stream);
LIBXL_STAILQ_INIT(stream-record_queue);
+libxl__conversion_helper_init(stream-chs);
}
void libxl__stream_read_start(libxl__egc *egc,
libxl__stream_read_state *stream)
{
libxl__datacopier_state *dc = stream-dc;
+STATE_AO_GC(stream-ao);
int rc = 0;
stream-running = true;
stream-phase = SRS_PHASE_NORMAL;
+if (stream-legacy) {
+/* Convert the legacy stream. */
+libxl__conversion_helper_state *chs = stream-chs;
+
+chs-ao = stream-ao;
+chs-legacy_fd = stream-fd;
+chs-hvm =
+(stream-dcs-guest_config-b_info.type == LIBXL_DOMAIN_TYPE_HVM);
+chs-completion_callback = conversion_done;
+
+rc = libxl__convert_legacy_stream(egc, stream-chs);
+
+if (rc) {
+LOG(ERROR, Failed to start the legacy stream conversion helper);
+goto err;
+}
+
+assert(stream-chs.v2_carefd);
+stream-fd = libxl__carefd_fd(stream-chs.v2_carefd);
+stream-dcs-libxc_fd = stream-fd;
+}
+/* stream-fd is now a v2 stream. */
+
dc-ao = stream-ao;
dc-readfd = stream-fd;
dc-writefd = -1;
@@ -522,6 +555,10 @@ static void stream_done(libxl__egc *egc,
if (stream-emu_carefd)
libxl__carefd_close(stream-emu_carefd);
+/* If we started a conversion helper, we took ownership of its carefd. */
+if (stream-chs.v2_carefd)
+libxl__carefd_close(stream-chs.v2_carefd);
+
/* The record queue had better be empty if the stream believes
* itself to have been successful. */
assert(LIBXL_STAILQ_EMPTY(stream-record_queue) || stream-rc);
@@ -529,7 +566,34 @@ static void stream_done(libxl__egc *egc,
LIBXL_STAILQ_FOREACH_SAFE(rec, stream-record_queue, entry, trec)
free_record(rec);
-stream-completion_callback(egc, stream, stream-rc);
+check_all_finished(egc, stream, stream-rc);
+}
+
+static void conversion_done(libxl__egc *egc,
+libxl__conversion_helper_state *chs, int rc)
+{
+libxl__stream_read_state *stream = CONTAINER_OF(chs, *stream, chs);
+
+check_all_finished(egc, stream, rc);
+}
+
+static void check_all_finished(libxl__egc *egc,
+ libxl__stream_read_state *stream, int rc)
+{
+STATE_AO_GC(stream-ao);
+
+if (!stream-rc rc) {
+/* First reported failure. Tear
[Xen-devel] [PATCH v3 11/28] tools/python: Libxc migration v2 infrastructure
Contains:
* Python implementation of the libxc migration v2 records
* Verification code for spec compliance
* Unit tests
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/python/setup.py|1 +
tools/python/xen/migration/libxc.py | 446 ++
tools/python/xen/migration/tests.py | 41
tools/python/xen/migration/verify.py | 37 +++
4 files changed, 525 insertions(+)
create mode 100644 tools/python/xen/migration/__init__.py
create mode 100644 tools/python/xen/migration/libxc.py
create mode 100644 tools/python/xen/migration/tests.py
create mode 100644 tools/python/xen/migration/verify.py
diff --git a/tools/python/setup.py b/tools/python/setup.py
index 439c429..5bf81be 100644
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -43,6 +43,7 @@ setup(name= 'xen',
version = '3.0',
description = 'Xen',
packages= ['xen',
+ 'xen.migration',
'xen.lowlevel',
],
ext_package = xen.lowlevel,
diff --git a/tools/python/xen/migration/__init__.py
b/tools/python/xen/migration/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/tools/python/xen/migration/libxc.py
b/tools/python/xen/migration/libxc.py
new file mode 100644
index 000..b0255ac
--- /dev/null
+++ b/tools/python/xen/migration/libxc.py
@@ -0,0 +1,446 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+
+Libxc Migration v2 streams
+
+Record structures as per docs/specs/libxc-migration-stream.pandoc, and
+verification routines.
+
+
+import sys
+
+from struct import calcsize, unpack
+
+from xen.migration.verify import StreamError, RecordError, VerifyBase
+
+# Image Header
+IHDR_FORMAT = !QIIHHI
+
+IHDR_MARKER = 0x
+IHDR_IDENT = 0x58454E46 # XENF in ASCII
+IHDR_VERSION = 2
+
+IHDR_OPT_BIT_ENDIAN = 0
+IHDR_OPT_LE = (0 IHDR_OPT_BIT_ENDIAN)
+IHDR_OPT_BE = (1 IHDR_OPT_BIT_ENDIAN)
+
+IHDR_OPT_RESZ_MASK = 0xfffe
+
+# Domain Header
+DHDR_FORMAT = IHHII
+
+DHDR_TYPE_x86_pv = 0x0001
+DHDR_TYPE_x86_hvm = 0x0002
+DHDR_TYPE_x86_pvh = 0x0003
+DHDR_TYPE_arm = 0x0004
+
+dhdr_type_to_str = {
+DHDR_TYPE_x86_pv : x86 PV,
+DHDR_TYPE_x86_hvm : x86 HVM,
+DHDR_TYPE_x86_pvh : x86 PVH,
+DHDR_TYPE_arm : ARM,
+}
+
+# Records
+RH_FORMAT = II
+
+REC_TYPE_end = 0x
+REC_TYPE_page_data= 0x0001
+REC_TYPE_x86_pv_info = 0x0002
+REC_TYPE_x86_pv_p2m_frames= 0x0003
+REC_TYPE_x86_pv_vcpu_basic= 0x0004
+REC_TYPE_x86_pv_vcpu_extended = 0x0005
+REC_TYPE_x86_pv_vcpu_xsave= 0x0006
+REC_TYPE_shared_info = 0x0007
+REC_TYPE_tsc_info = 0x0008
+REC_TYPE_hvm_context = 0x0009
+REC_TYPE_hvm_params = 0x000a
+REC_TYPE_toolstack= 0x000b
+REC_TYPE_x86_pv_vcpu_msrs = 0x000c
+REC_TYPE_verify = 0x000d
+REC_TYPE_checkpoint = 0x000e
+
+rec_type_to_str = {
+REC_TYPE_end : End,
+REC_TYPE_page_data: Page data,
+REC_TYPE_x86_pv_info : x86 PV info,
+REC_TYPE_x86_pv_p2m_frames: x86 PV P2M frames,
+REC_TYPE_x86_pv_vcpu_basic: x86 PV vcpu basic,
+REC_TYPE_x86_pv_vcpu_extended : x86 PV vcpu extended,
+REC_TYPE_x86_pv_vcpu_xsave: x86 PV vcpu xsave,
+REC_TYPE_shared_info : Shared info,
+REC_TYPE_tsc_info : TSC info,
+REC_TYPE_hvm_context : HVM context,
+REC_TYPE_hvm_params : HVM params,
+REC_TYPE_toolstack: Toolstack,
+REC_TYPE_x86_pv_vcpu_msrs : x86 PV vcpu msrs,
+REC_TYPE_verify : Verify,
+REC_TYPE_checkpoint : Checkpoint,
+}
+
+# page_data
+PAGE_DATA_FORMAT = II
+PAGE_DATA_PFN_MASK = (1L 52) - 1
+PAGE_DATA_PFN_RESZ_MASK = ((1L 60) - 1) ~((1L 52) - 1)
+
+# flags from xen/public/domctl.h: XEN_DOMCTL_PFINFO_* shifted by 32 bits
+PAGE_DATA_TYPE_SHIFT = 60
+PAGE_DATA_TYPE_LTABTYPE_MASK = (0x7L PAGE_DATA_TYPE_SHIFT)
+PAGE_DATA_TYPE_LTAB_MASK = (0xfL PAGE_DATA_TYPE_SHIFT)
+PAGE_DATA_TYPE_LPINTAB = (0x8L PAGE_DATA_TYPE_SHIFT) # Pinned
pagetable
+
+PAGE_DATA_TYPE_NOTAB = (0x0L PAGE_DATA_TYPE_SHIFT) # Regular page
+PAGE_DATA_TYPE_L1TAB = (0x1L PAGE_DATA_TYPE_SHIFT) # L1 pagetable
+PAGE_DATA_TYPE_L2TAB = (0x2L PAGE_DATA_TYPE_SHIFT) # L2 pagetable
+PAGE_DATA_TYPE_L3TAB = (0x3L PAGE_DATA_TYPE_SHIFT) # L3 pagetable
+PAGE_DATA_TYPE_L4TAB = (0x4L PAGE_DATA_TYPE_SHIFT) # L4 pagetable
+PAGE_DATA_TYPE_BROKEN= (0xdL PAGE_DATA_TYPE_SHIFT) # Broken
+PAGE_DATA_TYPE_XALLOC= (0xeL PAGE_DATA_TYPE_SHIFT) # Allocate-only
+PAGE_DATA_TYPE_XTAB
[Xen-devel] [PATCH v3 17/28] tools/libxl: Infrastructure for reading a libxl migration v2 stream
From: Ross Lagerwall ross.lagerw...@citrix.com
This contains the event machinery and state machines to read an act on
a non-checkpointed migration v2 stream (with the exception of the
xc_domain_restore() handling which is spliced later in a bisectable
way).
It also contains some boilerplate to help support checkpointed
streams, which shall be introduced in a later patch.
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: More descriptions of the internal state, shuffle function order, add
an _init() call, condense error handling
---
tools/libxl/Makefile|1 +
tools/libxl/libxl_internal.h| 53
tools/libxl/libxl_stream_read.c | 541 +++
3 files changed, 595 insertions(+)
create mode 100644 tools/libxl/libxl_stream_read.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index cc9c152..c71c5fe 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -94,6 +94,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
+ libxl_stream_read.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3f1fed8..c0e7720 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -19,6 +19,8 @@
#include libxl_osdeps.h /* must come before any other headers */
+#include libxl_sr_stream_format.h
+
#include assert.h
#include dirent.h
#include errno.h
@@ -3211,6 +3213,57 @@ typedef void libxl__domain_create_cb(libxl__egc *egc,
libxl__domain_create_state*,
int rc, uint32_t domid);
+/* State for manipulating a libxl migration v2 stream */
+typedef struct libxl__stream_read_state libxl__stream_read_state;
+
+typedef struct libxl__sr_record_buf {
+/* private to stream read helper */
+LIBXL_STAILQ_ENTRY(struct libxl__sr_record_buf) entry;
+libxl__sr_rec_hdr hdr;
+void *body; /* iff hdr.length != 0 */
+} libxl__sr_record_buf;
+
+struct libxl__stream_read_state {
+/* filled by the user */
+libxl__ao *ao;
+libxl__domain_create_state *dcs;
+int fd;
+void (*completion_callback)(libxl__egc *egc,
+libxl__stream_read_state *srs,
+int rc);
+/* Private */
+int rc;
+bool running;
+
+/* Main stream-reading data. */
+libxl__datacopier_state dc;
+libxl__sr_hdr hdr;
+LIBXL_STAILQ_HEAD(, libxl__sr_record_buf) record_queue;
+enum {
+SRS_PHASE_NORMAL,
+} phase;
+bool recursion_guard;
+
+/* Only used while actively reading a record from the stream. */
+libxl__sr_record_buf *incoming_record;
+
+/* Only used when processing an EMULATOR record. */
+libxl__datacopier_state emu_dc;
+libxl__carefd *emu_carefd;
+};
+
+_hidden void libxl__stream_read_init(libxl__stream_read_state *stream);
+_hidden void libxl__stream_read_start(libxl__egc *egc,
+ libxl__stream_read_state *stream);
+_hidden void libxl__stream_read_abort(libxl__egc *egc,
+ libxl__stream_read_state *stream, int
rc);
+static inline bool
+libxl__stream_read_inuse(const libxl__stream_read_state *stream)
+{
+return stream-running;
+}
+
+
struct libxl__domain_create_state {
/* filled in by user */
libxl__ao *ao;
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
new file mode 100644
index 000..e70c05a
--- /dev/null
+++ b/tools/libxl/libxl_stream_read.c
@@ -0,0 +1,541 @@
+/*
+ * Copyright (C) 2015 Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include libxl_osdeps.h /* must come before any other headers */
+
+#include libxl_internal.h
+
+/*
+ * Infrastructure for reading and acting on the contents of a libxl
+ * migration stream. There are a lot of moving parts
[Xen-devel] [PATCH v3 23/28] docs/libxl: Introduce CHECKPOINT_END to support migration v2 remus streams
In a remus scenario, libxc will write a CHECKPOINT record, then hand
ownership of the fd to libxl. Libxl then writes any records required
and finishes with a CHECKPOINT_END record, then hands ownership of the
fd back to libxc.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
docs/specs/libxl-migration-stream.pandoc | 14 +-
tools/libxl/libxl_sr_stream_format.h |1 +
tools/python/xen/migration/libxl.py | 11 +++
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/docs/specs/libxl-migration-stream.pandoc
b/docs/specs/libxl-migration-stream.pandoc
index 4192950..c24a434 100644
--- a/docs/specs/libxl-migration-stream.pandoc
+++ b/docs/specs/libxl-migration-stream.pandoc
@@ -119,7 +119,9 @@ type 0x: END
0x0003: EMULATOR_CONTEXT
- 0x0004 - 0x7FFF: Reserved for future _mandatory_
+ 0x0004: CHECKPOINT_END
+
+ 0x0005 - 0x7FFF: Reserved for future _mandatory_
records.
0x8000 - 0x: Reserved for future _optional_
@@ -203,3 +205,13 @@ indexIndex of this emulator for the domain, if
multiple
emulator_ctx Emulator context blob.
+
+CHECKPOINT\_END
+---
+
+A checkpoint end record marks the end of a checkpoint in the image.
+
+ 0 1 2 3 4 5 6 7 octet
++-+
+
+The end record contains no fields; its body_length is 0.
diff --git a/tools/libxl/libxl_sr_stream_format.h
b/tools/libxl/libxl_sr_stream_format.h
index f4f790b..3f3c497 100644
--- a/tools/libxl/libxl_sr_stream_format.h
+++ b/tools/libxl/libxl_sr_stream_format.h
@@ -35,6 +35,7 @@
#define REC_TYPE_LIBXC_CONTEXT 0x0001U
#define REC_TYPE_XENSTORE_DATA 0x0002U
#define REC_TYPE_EMULATOR_CONTEXT0x0003U
+#define REC_TYPE_CHECKPOINT_END 0x0004U
typedef struct libxl__sr_emulator_hdr
{
diff --git a/tools/python/xen/migration/libxl.py
b/tools/python/xen/migration/libxl.py
index 4e1f4f8..415502e 100644
--- a/tools/python/xen/migration/libxl.py
+++ b/tools/python/xen/migration/libxl.py
@@ -36,12 +36,14 @@ REC_TYPE_end = 0x
REC_TYPE_libxc_context= 0x0001
REC_TYPE_xenstore_data= 0x0002
REC_TYPE_emulator_context = 0x0003
+REC_TYPE_checkpoint_end = 0x0004
rec_type_to_str = {
REC_TYPE_end : End,
REC_TYPE_libxc_context: Libxc context,
REC_TYPE_xenstore_data: Xenstore data,
REC_TYPE_emulator_context : Emulator context,
+REC_TYPE_checkpoint_end : Checkpoint end,
}
# emulator_context
@@ -176,6 +178,13 @@ class VerifyLibxl(VerifyBase):
self.info( Index %d, type %s % (emu_idx,
emulator_id_to_str[emu_id]))
+def verify_record_checkpoint_end(self, content):
+ Checkpoint end record
+
+if len(content) != 0:
+raise RecordError(Checkpoint end record with non-zero length)
+
+
record_verifiers = {
REC_TYPE_end:
VerifyLibxl.verify_record_end,
@@ -185,4 +194,6 @@ record_verifiers = {
VerifyLibxl.verify_record_xenstore_data,
REC_TYPE_emulator_context:
VerifyLibxl.verify_record_emulator_context,
+REC_TYPE_checkpoint_end:
+VerifyLibxl.verify_record_checkpoint_end,
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 28/28] tools/libxl: Drop all knowledge of toolstack callbacks
Libxl has now been fully adjusted not to need them.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_dom.c|1 -
tools/libxl/libxl_internal.h |2 --
tools/libxl/libxl_save_callout.c | 39 +---
tools/libxl/libxl_save_helper.c| 29 ---
tools/libxl/libxl_save_msgs_gen.pl |7 ++-
5 files changed, 3 insertions(+), 75 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 98eb824..cbbb6ba 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -2116,7 +2116,6 @@ void libxl__domain_suspend(libxl__egc *egc,
libxl__domain_suspend_state *dss)
callbacks-suspend = libxl__domain_suspend_callback;
callbacks-switch_qemu_logdirty =
libxl__domain_suspend_common_switch_qemu_logdirty;
-dss-sws.shs.callbacks.save.toolstack_save = libxl__toolstack_save;
dss-sws.ao = dss-ao;
dss-sws.dss = dss;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 176c360..5cacbd4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2699,8 +2699,6 @@ _hidden void libxl__datacopier_prefixdata(libxl__egc*,
libxl__datacopier_state*,
typedef struct libxl__srm_save_callbacks {
libxl__srm_save_autogen_callbacks a;
-int (*toolstack_save)(uint32_t domid, uint8_t **buf,
- uint32_t *len, void *data);
} libxl__srm_save_callbacks;
typedef struct libxl__srm_restore_callbacks {
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index b8feb9f..03d1278 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -80,41 +80,12 @@ void libxl__xc_domain_save(libxl__egc *egc,
libxl__domain_suspend_state *dss,
libxl__save_helper_state *shs)
{
STATE_AO_GC(dss-ao);
-int r, rc, toolstack_data_fd = -1;
-uint32_t toolstack_data_len = 0;
-
-/* Resources we need to free */
-uint8_t *toolstack_data_buf = 0;
unsigned cbflags =
libxl__srm_callout_enumcallbacks_save(shs-callbacks.save.a);
-if (shs-callbacks.save.toolstack_save) {
-r = shs-callbacks.save.toolstack_save
-(dss-domid, toolstack_data_buf, toolstack_data_len, dss);
-if (r) { rc = ERROR_FAIL; goto out; }
-
-shs-toolstack_data_file = tmpfile();
-if (!shs-toolstack_data_file) {
-LOGE(ERROR, cannot create toolstack data tmpfile);
-rc = ERROR_FAIL;
-goto out;
-}
-toolstack_data_fd = fileno(shs-toolstack_data_file);
-
-r = libxl_write_exactly(CTX, toolstack_data_fd,
-toolstack_data_buf, toolstack_data_len,
-toolstack data tmpfile, 0);
-if (r) { rc = ERROR_FAIL; goto out; }
-
-/* file position must be reset before passing to libxl-save-helper. */
-r = lseek(toolstack_data_fd, 0, SEEK_SET);
-if (r) { rc = ERROR_FAIL; goto out; }
-}
-
const unsigned long argnums[] = {
dss-domid, 0, 0, dss-xcflags, dss-hvm,
-toolstack_data_fd, toolstack_data_len,
cbflags,
};
@@ -125,18 +96,10 @@ void libxl__xc_domain_save(libxl__egc *egc,
libxl__domain_suspend_state *dss,
shs-caller_state = dss;
shs-need_results = 0;
-free(toolstack_data_buf);
-
run_helper(egc, shs, --save-domain, dss-fd,
- toolstack_data_fd, 1,
+ NULL, 0,
argnums, ARRAY_SIZE(argnums));
return;
-
- out:
-free(toolstack_data_buf);
-if (shs-toolstack_data_file) fclose(shs-toolstack_data_file);
-
-libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
}
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
index f196786..1622bb7 100644
--- a/tools/libxl/libxl_save_helper.c
+++ b/tools/libxl/libxl_save_helper.c
@@ -213,32 +213,8 @@ int helper_getreply(void *user)
/*- other callbacks -*/
-static int toolstack_save_fd;
-static uint32_t toolstack_save_len;
static struct save_callbacks helper_save_callbacks;
-static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
- uint32_t *len, void *data)
-{
-int r;
-
-assert(toolstack_save_fd 0);
-
-/* This is a hack for remus */
-if (helper_save_callbacks.checkpoint) {
-r = lseek(toolstack_save_fd, 0, SEEK_SET);
-if (r) fail(errno,rewind toolstack data tmpfile);
-}
-
-*buf = xmalloc(toolstack_save_len);
-r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
-if (r0) fail(errno,read toolstack data);
-if (r==0) fail(0,read toolstack data eof);
-
-*len = toolstack_save_len;
-return 0;
-}
-
static void startup(const char *op) {
[Xen-devel] [libvirt test] 59488: regressions - FAIL
flight 59488 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/59488/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 58842 build-i386-pvops 5 kernel-build fail REGR. vs. 58842 build-amd64-pvops 5 kernel-build fail REGR. vs. 58842 build-armhf-pvops 5 kernel-build fail REGR. vs. 58842 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 4ffb21c89a6b9ae2b4bfd2999c24b01433e360a9 baseline version: libvirt d10a5f58c75e7eb5943b44cc36a1e768adb2cdb0 Last test of basis58842 2015-06-23 04:23:54 Z 20 days Failing since 58870 2015-06-24 04:20:11 Z 19 days 17 attempts Testing same since59428 2015-07-11 04:20:59 Z2 days3 attempts People who touched revisions under test: Andrea Bolognani abolo...@redhat.com Boris Fiuczynski fiu...@linux.vnet.ibm.com Cédric Bosdonnat cbosdon...@suse.com Daniel Veillard veill...@redhat.com Dmitry Guryanov dgurya...@parallels.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Guido Günther a...@sigxcpu.org Jim Fehlig jfeh...@suse.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Laine Stump la...@laine.org Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@virtuozzo.com Michal Dubiel m...@semihalf.com Michal Privoznik mpriv...@redhat.com Mikhail Feoktistov mfeoktis...@virtuozzo.com Nikolay Shirokovskiy nshirokovs...@parallels.com Nikolay Shirokovskiy nshirokovs...@virtuozzo.com Pavel Fedin p.fe...@samsung.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Prerna Saxena pre...@linux.vnet.ibm.com Serge Hallyn serge.hal...@ubuntu.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt fail build-amd64-pvopsfail build-armhf-pvopsfail build-i386-pvops fail test-amd64-amd64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2619 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/3] arm64: Add Xen boot support file
From: Fu Wei fu@linaro.org
This patch adds Xen boot support file:
grub-core/loader/arm64/xen_boot.c
include/grub/arm64/xen_boot.h
This patch also adds commands register code and hearder file into
grub-core/loader/arm64/linux.c
- This adds support for the Xen boot on ARM specification for arm64.
- The implementation for Xen is following Multiboot on ARM Specification:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
and xen/docs/misc/arm/device-tree/booting.txt in Xen source code.
- The multiboot/module commands have existed,
so we use xen_hypervisor/xen_module instead.
- This Xen boot support is built into linux module for aarch64.
- Adding this functionality to the existing linux module is for
reusing the existing code of devicetree.
Signed-off-by: Fu Wei fu@linaro.org
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/arm64/linux.c| 6 +
grub-core/loader/arm64/xen_boot.c | 615 ++
include/grub/arm64/xen_boot.h | 115 +++
4 files changed, 737 insertions(+)
create mode 100644 grub-core/loader/arm64/xen_boot.c
create mode 100644 include/grub/arm64/xen_boot.h
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index a6101de..01f8261 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1659,6 +1659,7 @@ module = {
ia64_efi = loader/ia64/efi/linux.c;
arm = loader/arm/linux.c;
arm64 = loader/arm64/linux.c;
+ arm64 = loader/arm64/xen_boot.c;
fdt = lib/fdt.c;
common = loader/linux.c;
common = lib/cmdline.c;
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index 987f5b9..7ae9bde 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -26,6 +26,7 @@
#include grub/mm.h
#include grub/types.h
#include grub/cpu/linux.h
+#include grub/cpu/xen_boot.h
#include grub/efi/efi.h
#include grub/efi/pe32.h
#include grub/i18n.h
@@ -477,6 +478,9 @@ GRUB_MOD_INIT (linux)
cmd_devicetree =
grub_register_command (devicetree, grub_cmd_devicetree, 0,
N_(Load DTB file.));
+
+ grub_arm64_linux_register_xen_boot_command (mod, loaded);
+
my_mod = mod;
}
@@ -485,4 +489,6 @@ GRUB_MOD_FINI (linux)
grub_unregister_command (cmd_linux);
grub_unregister_command (cmd_initrd);
grub_unregister_command (cmd_devicetree);
+
+ grub_arm64_linux_unregister_xen_boot_command ();
}
diff --git a/grub-core/loader/arm64/xen_boot.c
b/grub-core/loader/arm64/xen_boot.c
new file mode 100644
index 000..23bd00e
--- /dev/null
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -0,0 +1,615 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2014 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include grub/cache.h
+#include grub/charset.h
+#include grub/command.h
+#include grub/err.h
+#include grub/file.h
+#include grub/fdt.h
+#include grub/linux.h
+#include grub/list.h
+#include grub/loader.h
+#include grub/misc.h
+#include grub/mm.h
+#include grub/types.h
+#include grub/cpu/linux.h
+#include grub/cpu/xen_boot.h
+#include grub/efi/efi.h
+#include grub/efi/pe32.h
+#include grub/i18n.h
+#include grub/lib/cmdline.h
+
+static grub_dl_t linux_mod;
+static int *loaded;
+
+static struct xen_boot_binary *xen_hypervisor;
+static struct xen_boot_binary *module_head;
+static const grub_size_t module_default_align[] = {
+ MODULE_IMAGE_MIN_ALIGN,
+ MODULE_INITRD_MIN_ALIGN,
+ MODULE_OTHER_MIN_ALIGN,
+ MODULE_CUSTOM_MIN_ALIGN
+};
+
+static void *xen_boot_fdt;
+static const compat_string_struct_t default_compat_string[] = {
+ FDT_COMPATIBLE (MODULE_IMAGE_COMPATIBLE),
+ FDT_COMPATIBLE (MODULE_INITRD_COMPATIBLE),
+ FDT_COMPATIBLE (MODULE_OTHER_COMPATIBLE)
+};
+
+
+/* Parse all the options of xen_module command. For now, we support
+ (1) --type the compatible stream
+ (2) --nounzip
+ We also set up the type of module in this function.
+ If there are some --type options in the command line,
+ we make a custom compatible stream in this function. */
+static grub_err_t
+set_module_type (struct xen_boot_binary *module, int argc, char *argv[],
+int *file_name_index)
+{
+ char **compat_string_temp_array =
+(char **) grub_zalloc (sizeof (char *) * argc);
+ static module_type_t default_type = MODULE_IMAGE;
+
[Xen-devel] [PATCH v2 3/3] arm64: Add the introduction of Xen boot command
From: Fu Wei fu@linaro.org
This patch adds the introduction of xen_hypervisor/xen_module commands
in docs/grub.texi
Signed-off-by: Fu Wei fu@linaro.org
---
docs/grub.texi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index b9f41a7..3bd2fc3 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3839,6 +3839,9 @@ you forget a command, you can run the command
@command{help}
@comment * vbeinfo:: List available video modes
* verify_detached:: Verify detached digital signature
* videoinfo:: List available video modes
+@comment * xen_hypervisor/xen_module:: Xen boot command, for arm64 only
+* xen_hypervisor:: Load xen hypervisor binary on arm64
+* xen_module:: Load module for xen hypervisor on arm64
@end menu
@@ -5102,6 +5105,30 @@ successfully. If validation fails, it is set to a
non-zero value.
List available video modes. If resolution is given, show only matching modes.
@end deffn
+@node xen_hypervisor
+@subsection xen_hypervisor
+
+@deffn Command xen_hypervisor file [arguments] @dots{}
+Load a Xen hypervisor binary from @var{file}. The rest of the
+line is passed verbatim as the @dfn{kernel command-line}. Any Xen module must
+be reloaded after using this command (@pxref{xen_module}).
+This command is only available on ARM64 systems.
+@end deffn
+
+@node xen_module
+@subsection xen_module
+
+@deffn Command xen_module [--type compatible stream] file [arguments]
+Load a module for xen hypervisor binary. The rest of the
+line is passed verbatim as the module command line.
+This command is only available on ARM64 systems.
+
+--type is an option which allow the module command to take compatible string.
+This would override default compatible string for this module.
+See
@uref{http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot},
+to obtain more information.
+@end deffn
+
@node Networking commands
@section The list of networking commands
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters
On 2015/7/13 17:40, Ian Campbell wrote:
On Mon, 2015-07-13 at 17:31 +0800, Chen, Tiejun wrote:
I still can't understand what I'm missing here after compared to other
contexts inside xlu_pci_parse_bdf().
Perhaps comparing to the CODING_STYLE document would help?
Looks the whole xlu_pci_parse_bdf() doesn't follow that,
if ( !strcmp(optkey, msitranslate) ) {
pcidev-msitranslate = atoi(tok);
}else if ( !strcmp(optkey, power_mgmt) ) {
pcidev-power_mgmt = atoi(tok);
}else if ( !strcmp(optkey, permissive) ) {
pcidev-permissive = atoi(tok);
}else if ( !strcmp(optkey, seize) ) {
pcidev-seize = atoi(tok);
}else if ( !strcmp(optkey, rdm_policy) ) {
So I can do this as you're expecting now, but seems our change would
make the code style very inconsistent inside this function.
Thanks
Tiejun
So I have to paste this entirely,
}else if ( !strcmp(optkey, rdm_policy) ) {
Should be:
} else if (!strcmp(optkey, rdm_policy)) {
i.e. space after } before else and no extra spaces inside the if
condition.
if ( !strcmp(tok, strict) ) {
if (!strcmp(tok, strict)) {
Again no spaces within the if.
pcidev-rdm_policy = LIBXL_RDM_RESERVE_POLICY_STRICT;
}else if ( !strcmp(tok, relaxed) ) {
Again add a space after } and remove those inside the if condition.
pcidev-rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED;
}else{
Should be:
} else {
XLU__PCI_ERR(cfg, %s is not an valid PCI RDM
property
policy: 'strict' or
'relaxed'.,
tok);
goto parse_error;
}
}else{
and again } else {
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters
On Mon, 2015-07-13 at 17:55 +0800, Chen, Tiejun wrote:
On 2015/7/13 17:40, Ian Campbell wrote:
On Mon, 2015-07-13 at 17:31 +0800, Chen, Tiejun wrote:
I still can't understand what I'm missing here after compared to other
contexts inside xlu_pci_parse_bdf().
Perhaps comparing to the CODING_STYLE document would help?
Looks the whole xlu_pci_parse_bdf() doesn't follow that,
if ( !strcmp(optkey, msitranslate) ) {
pcidev-msitranslate = atoi(tok);
}else if ( !strcmp(optkey, power_mgmt) ) {
pcidev-power_mgmt = atoi(tok);
}else if ( !strcmp(optkey, permissive) ) {
pcidev-permissive = atoi(tok);
}else if ( !strcmp(optkey, seize) ) {
pcidev-seize = atoi(tok);
}else if ( !strcmp(optkey, rdm_policy) ) {
So I can do this as you're expecting now, but seems our change would
make the code style very inconsistent inside this function.
I think one could make an argument that the exception described in the
first section of tools/libxl/CODING_STYLE applies here for the
whitespace issues, but not for the long lines I think.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 06/13] toolstack/libvirt: guest migrate, save and restore support
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote:
Perhaps the libvirt part of the check_for_command stuff ought to be
moved here? Otherwise we are claiming support before the code is
actually willing to try to do so.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Toolstack/libvirt.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index ddf84df..3dc1856 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -105,17 +105,22 @@ sub saverestore_check ($) {
sub migrate ($) {
my ($self,$gho,$dst,$timeout) = @_;
-die Migration is not yet supported on libvirt.;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho, virsh migrate $gn $dst, $timeout);
}
sub save () {
my ($self,$gho,$f,$timeout) = @_;
-die Save is not yet supported on libvirt.;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho, virsh save $gn $f, $timeout);
}
sub restore () {
my ($self,$gho,$f,$timeout) = @_;
-die Restore is not yet supported on libvirt.;
+my $ho = $self-{Host};
+target_cmd_root($ho, virsh restore $f, $timeout);
}
1;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
-Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 13:08 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 03:04 PM, Paul Durrant wrote: -Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- boun...@lists.xen.org] On Behalf Of Paul Durrant Sent: 13 July 2015 11:12 To: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:42 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:05 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:03 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)
[Xen-devel] [rumpuserxen test] 59489: regressions - FAIL
flight 59489 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/59489/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 build-i386-pvops 5 kernel-build fail REGR. vs. 33866 build-amd64-pvops 5 kernel-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad Last test of basis33866 2015-01-28 04:19:26 Z 166 days Failing since 34129 2015-02-03 04:21:40 Z 160 days 115 attempts Testing same since50441 2015-04-15 20:51:55 Z 88 days 70 attempts People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopsfail build-i386-pvops fail build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 for Xen 4.6 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler
On 11.07.15 at 06:52, lichong...@gmail.com wrote:
@@ -1162,8 +1176,82 @@ rt_dom_cntl(
}
spin_unlock_irqrestore(prv-lock, flags);
break;
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+for ( index = 0; index op-u.v.nr_vcpus; index++ )
+{
+if ( copy_from_guest_offset(local_sched,
+ op-u.v.vcpus, index, 1) )
+{
+rc = -EFAULT;
+break;
+}
+if ( local_sched.vcpuid = d-max_vcpus ||
+ d-vcpu[local_sched.vcpuid] == NULL )
+{
+rc = -EINVAL;
+break;
+}
+svc = rt_vcpu(d-vcpu[local_sched.vcpuid]);
+
+local_sched.s.rtds.budget = svc-budget / MICROSECS(1);
+local_sched.s.rtds.period = svc-period / MICROSECS(1);
+
+if ( __copy_to_guest_offset(op-u.v.vcpus, index,
+local_sched, 1) )
+{
+rc = -EFAULT;
+break;
+}
+if( hypercall_preempt_check() )
+{
+rc = -ERESTART;
+break;
+}
I still don't see how this is supposed to work.
+}
+spin_unlock_irqrestore(prv-lock, flags);
+break;
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+for( index = 0; index op-u.v.nr_vcpus; index++ )
+{
+if ( copy_from_guest_offset(local_sched,
+ op-u.v.vcpus, index, 1) )
+{
+rc = -EFAULT;
+break;
+}
+if ( local_sched.vcpuid = d-max_vcpus ||
+ d-vcpu[local_sched.vcpuid] == NULL )
+{
+rc = -EINVAL;
+break;
+}
+svc = rt_vcpu(d-vcpu[local_sched.vcpuid]);
+period = MICROSECS(local_sched.s.rtds.period);
+budget = MICROSECS(local_sched.s.rtds.budget);
+if ( period MICROSECS(10) || period RTDS_MAX_PERIOD ||
+ budget MICROSECS(10) || budget period )
Apart from numerous coding style issues I think the first of the
checks in this if() is redundant (covered by the combination of
the last two ones) and hence would better be dropped.
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1052,10 +1052,22 @@ long sched_adjust(struct domain *d, struct
xen_domctl_scheduler_op *op)
if ( ret )
return ret;
-if ( (op-sched_id != DOM2OP(d)-sched_id) ||
- ((op-cmd != XEN_DOMCTL_SCHEDOP_putinfo)
- (op-cmd != XEN_DOMCTL_SCHEDOP_getinfo)) )
+if ( op-sched_id != DOM2OP(d)-sched_id )
return -EINVAL;
+else
+switch ( op-cmd )
+{
+case XEN_DOMCTL_SCHEDOP_putinfo:
+break;
+case XEN_DOMCTL_SCHEDOP_getinfo:
+break;
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+break;
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+break;
Only this break should stay, the three earlier ones should be dropped
as redundant.
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -330,31 +330,56 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t);
#define XEN_SCHEDULER_ARINC653 7
#define XEN_SCHEDULER_RTDS 8
+typedef struct xen_domctl_sched_sedf {
+uint64_aligned_t period;
+uint64_aligned_t slice;
+uint64_aligned_t latency;
+uint32_t extratime;
+uint32_t weight;
+} xen_domctl_sched_sedf_t;
+
+typedef struct xen_domctl_sched_credit {
+uint16_t weight;
+uint16_t cap;
+} xen_domctl_sched_credit_t;
+
+typedef struct xen_domctl_sched_credit2 {
+uint16_t weight;
+} xen_domctl_sched_credit2_t;
+
+typedef struct xen_domctl_sched_rtds {
+uint32_t period;
+uint32_t budget;
+} xen_domctl_sched_rtds_t;
+
+typedef struct xen_domctl_schedparam_vcpu {
+union {
+xen_domctl_sched_credit_t credit;
+xen_domctl_sched_credit2_t credit2;
+xen_domctl_sched_rtds_t rtds;
+} s;
+uint16_t vcpuid;
+uint16_t padding;
This pads to a 32-bit boundary, leaving another 32-bit hole.
+} xen_domctl_schedparam_vcpu_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_schedparam_vcpu_t);
+
/* Set or get info? */
#define XEN_DOMCTL_SCHEDOP_putinfo 0
#define XEN_DOMCTL_SCHEDOP_getinfo 1
+#define XEN_DOMCTL_SCHEDOP_putvcpuinfo 2
+#define XEN_DOMCTL_SCHEDOP_getvcpuinfo 3
struct xen_domctl_scheduler_op {
uint32_t sched_id; /* XEN_SCHEDULER_* */
uint32_t cmd; /* XEN_DOMCTL_SCHEDOP_* */
union {
-struct xen_domctl_sched_sedf {
-uint64_aligned_t period;
-uint64_aligned_t slice;
-uint64_aligned_t latency;
-uint32_t
Re: [Xen-devel] [PATCH v8 05/11] xen: grant_table: implement grant_table_warn_active_grants()
On Mon, 2015-07-13 at 09:45 +0100, Jan Beulich wrote: On 10.07.15 at 18:24, konrad.w...@oracle.com wrote: On Tue, Jun 23, 2015 at 06:11:47PM +0200, Vitaly Kuznetsov wrote: Log first 10 active grants of a domain. This function is going to be used for soft reset, active grants on this path usually mean misbehaving backends refusing to release their mappings on shutdown. Is there an particular reason 10 was choosen instead of 42 for example :-) Also the 10 should probably have an #define for it. Or even be command line controllable. That sounds like overkill to me, what's wrong with some random hardcoded number for a simple debug aid like this? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 05/11] xen: grant_table: implement grant_table_warn_active_grants()
Jan Beulich jbeul...@suse.com writes: On 13.07.15 at 11:08, ian.campb...@citrix.com wrote: On Mon, 2015-07-13 at 09:45 +0100, Jan Beulich wrote: On 10.07.15 at 18:24, konrad.w...@oracle.com wrote: On Tue, Jun 23, 2015 at 06:11:47PM +0200, Vitaly Kuznetsov wrote: Log first 10 active grants of a domain. This function is going to be used for soft reset, active grants on this path usually mean misbehaving backends refusing to release their mappings on shutdown. Is there an particular reason 10 was choosen instead of 42 for example :-) Also the 10 should probably have an #define for it. Or even be command line controllable. That sounds like overkill to me, what's wrong with some random hardcoded number for a simple debug aid like this? From briefly looking at the code it seemed to be more than just a debug aid (i.e. failing the operation if the count was exceeded). If the number indeed only controls how many entries get printed, then a #define certainly is fine. Yes, it is just a debug aid in cases something goes wrong in future. This info is supposed to be useful for hardware domain admin to help finding misbehaving backends. -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 8/9] xl: fix main_cpupoolcreate
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
Don't dereference extra_config if it's NULL. Don't leak extra_config in
the end.
Subject should be more descriptive. xl: correct handling of
extra_config in main_cpupoolcreate perhaps? (It's a lot easier to write
non-vague messages for patches which only do one thing)
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/xl_cmdimpl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 971209c..d44eb4b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7228,7 +7228,7 @@ int main_cpupoolcreate(int argc, char **argv)
else
config_src=command line;
-if (strlen(extra_config)) {
+if (extra_config strlen(extra_config)) {
if (config_len INT_MAX - (strlen(extra_config) + 2)) {
fprintf(stderr, Failed to attach extra configration\n);
There's a typo in this line of context...
goto out;
@@ -7365,6 +7365,7 @@ out_cfg:
out:
free(name);
free(config_data);
+free(extra_config);
return rc;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
-Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:42 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:05 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:03 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)[82d080198b49] x86_emulate+0x56c9/0x13088 (XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281 (XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12 (XEN)[82d0801cb63e] handle_mmio+0x54/0xd2 (XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46 (XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d (XEN)[82d0801ee7d1]
Re: [Xen-devel] [PATCH 7/9] libxl: qmp_init_handler can return NULL
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
(although the only actual reason for a failure today is a memory
allocation failure, which ought to abort really).
---
tools/libxl/libxl_qmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6484f5e..965c507 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -694,6 +694,7 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
uint32_t domid)
char *qmp_socket;
qmp = qmp_init_handler(gc, domid);
+if (!qmp) return NULL;
qmp_socket = GCSPRINTF(%s/qmp-libxl-%d, libxl__run_dir_path(), domid);
if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) 0) {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 1/1] libxl: set stub domain size based on VRAM size
On Mon, 2015-07-13 at 11:22 +0100, Ian Jackson wrote: Ian Jackson writes (Re: [PATCH V2 1/1] libxl: set stub domain size based on VRAM size): Eric Shelton writes ([PATCH V2 1/1] libxl: set stub domain size based on VRAM size): Allocate additional memory to the stub domain for qemu-traditional if more than 4 MB is assigned to the video adapter to avoid out of memory condition for QEMU. Acked-by: Ian Jackson ian.jack...@eu.citrix.com This is IMO a bugfix so I am queueing it for 4.6. My build test failed. It turns out that max() is no good because the types of `4096' and `guest_config-b_info.video_memkb' are not the same. In a moment I am going to send a v3 which uses max_t and uint64_t (which is the type of the memkb fields and also obviously correct). Eric already sent a v3 in 1436650242-1067-2-git-send-email-eshel...@pobox.com which avoids the use of max in a different way. I think his approach looked fine. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 59483: regressions - FAIL
flight 59483 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/59483/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 59059 test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-freebsd10-amd64 12 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore fail REGR. vs. 59059 test-amd64-amd64-xl-qemuu-winxpsp3 11 guest-saverestore fail REGR. vs. 59059 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-saverestore fail REGR. vs. 59059 test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestorefail REGR. vs. 59059 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-saverestore fail in 59435 REGR. vs. 59059 test-amd64-amd64-xl-qemuu-ovmf-amd64 11 guest-saverestore fail in 59465 REGR. vs. 59059 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 7 host-ping-check-xen fail in 59465 pass in 59483 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 59435 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 59465 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail pass in 59465 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 14 guest-start.2fail in 59465 REGR. vs. 59059 test-amd64-amd64-libvirt 11 guest-start fail like 59059 test-amd64-i386-libvirt 11 guest-start fail like 59059 test-amd64-i386-libvirt-xsm 11 guest-start fail like 59059 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 59465 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: qemuu6169b60285fe1ff730d840a49527e721bfb30899 baseline version: qemuu35360642d043c2a5366e8a04a10e5545e7353bd5 Last test of basis59059 2015-07-05 10:39:20 Z8 days Failing since 59109 2015-07-06 14:58:21 Z6 days8 attempts Testing same since59387 2015-07-10 15:45:24 Z2 days4 attempts People who touched revisions under test: Alberto Garcia be...@igalia.com Alex Williamson alex.william...@redhat.com Alexander Graf ag...@suse.de Alexey Kardashevskiy a...@ozlabs.ru Alvise Rigo a.r...@virtualopensystems.com Andreas Färber afaer...@suse.de Andrew Jones drjo...@redhat.com Artyom Tarasenko atar4q...@gmail.com Aurelien Jarno aurel...@aurel32.net Benjamin Herrenschmidt b...@kernel.crashing.org Bharata B Rao bhar...@linux.vnet.ibm.com Brian Kress kre...@moose.net Claudio Fontana claudio.font...@huawei.com Cormac O'Brien i.am.cormac.obr...@gmail.com Cornelia Huck cornelia.h...@de.ibm.com Daniel P. Berrange berra...@redhat.com David Gibson da...@gibson.dropbear.id.au Denis V. Lunev d...@openvz.org Dmitry Osipenko dig...@gmail.com Dr. David Alan Gilbert dgilb...@redhat.com Eduardo Habkost ehabk...@redhat.com Eric Auger eric.au...@linaro.org Fam Zheng f...@redhat.com Gabriel Laupre glau...@chelsio.com Gavin Shan gws...@linux.vnet.ibm.com Gerd Hoffmann kra...@redhat.com Gonglei arei.gong...@huawei.com Greg Kurz gk...@linux.vnet.ibm.com Hannes Reinecke h...@suse.de Igor Mammedov imamm...@redhat.com James Hogan james.ho...@imgtec.com Jan Kiszka jan.kis...@siemens.com Johannes Schlatow schla...@ida.ing.tu-bs.de John Snow js...@redhat.com Juan Quintela quint...@redhat.com Justin Ossevoort jus...@quarantainenet.nl Kirk Allan kal...@suse.com Laszlo Ersek ler...@redhat.com Laurent Vivier
Re: [Xen-devel] [PATCH V2 1/1] libxl: set stub domain size based on VRAM size
Ian Campbell writes (Re: [PATCH V2 1/1] libxl: set stub domain size based on VRAM size): On Mon, 2015-07-13 at 11:22 +0100, Ian Jackson wrote: In a moment I am going to send a v3 which uses max_t and uint64_t (which is the type of the memkb fields and also obviously correct). Eric already sent a v3 in 1436650242-1067-2-git-send-email-eshel...@pobox.com which avoids the use of max in a different way. I think his approach looked fine. Well, it does also reduce the stubdom memory when the video memory is 4Mby. That sounds plausible to me but at the very least the commit message needs changing, and maybe we should wait a bit to see if one of the qemu experts objects. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 03/13] osstest migrate support check catch - variables
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote:
@@ -300,7 +300,9 @@ proc run-job/test-pair {} {
}
proc test-guest-migr {g} {
-if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
+set to_reap [spawn-ts . = ts-migrate-support-check + host $g]
Most other uses of spawn-ts use [eval spawn-ts stuff]. I think those
are just trying to expand a $args into multiple arguments to spawn-ts,
and hence that isn't needed here (because $g is a singleton argument
already). But TBH I don't know...
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6] tools: libxl: Handle failure to create qemu dm logfile
If libxl_create_logfile fails for some reason then
libxl__create_qemu_logfile previously just carried on and dereferenced
the uninitialised logfile.
Check for the error from libxl_create_logfile, which has already
logged for us.
This was reported as Debian bug #784880.
Reported-by: Russell Coker russ...@coker.com.au
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: 784...@bugs.debian.org
---
Should be backported.
---
tools/libxl/libxl_dm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ad434f0..8ed2d2e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -46,9 +46,11 @@ static const char *qemu_xen_path(libxl__gc *gc)
static int libxl__create_qemu_logfile(libxl__gc *gc, char *name)
{
char *logfile;
-int logfile_w;
+int rc, logfile_w;
+
+rc = libxl_create_logfile(CTX, name, logfile);
+if (rc) return rc;
-libxl_create_logfile(CTX, name, logfile);
logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
free(logfile);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)[82d080198b49] x86_emulate+0x56c9/0x13088 (XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281 (XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12 (XEN)[82d0801cb63e] handle_mmio+0x54/0xd2 (XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46 (XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d (XEN)[82d0801ee7d1] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back enough to apply V4 on top of it (which has been thoroughly tested on Thursday), and it still happens, so this would at least appear to be unrelated at this point (other than the fact that our use case is maybe somewhat unusual with heavy emulation). I'll keep digging, but since this is a busy time for Xen I thought I'd issue a heads-up here as soon as possible, in case the problem is obvious for somebody and it helps getting it fixed sooner. In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a deliberate split between stdvga_mem_accept() and stdvga_mem_complete() about locking and unlocking the stdvga lock. At a guess, the previous chain of execution accidentally omitted the
Re: [Xen-devel] [PATCH v2] x86/hvm: add support for broadcast of buffered ioreqs...
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 13 July 2015 09:44
To: Paul Durrant
Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir (Xen.org)
Subject: Re: [PATCH v2] x86/hvm: add support for broadcast of buffered
ioreqs...
On 10.07.15 at 18:07, paul.durr...@citrix.com wrote:
@@ -2710,17 +2711,21 @@ int hvm_send_assist_req(struct
hvm_ioreq_server *s, ioreq_t *proto_p)
return X86EMUL_UNHANDLEABLE;
}
-void hvm_broadcast_assist_req(ioreq_t *p)
+int hvm_broadcast_ioreq(ioreq_t *p, bool_t buffered)
{
struct domain *d = current-domain;
struct hvm_ioreq_server *s;
+unsigned int failed = 0;
ASSERT(p-type == IOREQ_TYPE_INVALIDATE);
list_for_each_entry ( s,
d-arch.hvm_domain.ioreq_server.list,
list_entry )
-(void) hvm_send_assist_req(s, p);
+if ( hvm_send_ioreq(s, p, buffered) == X86EMUL_UNHANDLEABLE )
+failed++;
+
+return failed;
I'll try to remember fixing up the mismatch between function return
type and return expression upon commit. Looks good beyond that.
Ok. Thanks,
Paul
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM
Do you mean I should merge them as one as possible? Factor it out means to break out into a separate function (or maybe a macro or something, but in this case a function is appropriate). So in this case take the two sets of similar code, combine them into a function with appropriate arguments, and then call that function in both places. Finding multiple occurrences of very similar code is usually a sign that refactoring is needed. Thanks for you explanation. But seems not be possible because we have seveal combinations of these two conditions, strategy = LIBXL_RDM_RESERVE_STRATEGY_HOST and one or pci devices are also passes through. [snip] Sorry I can't figure out a good name here :) Any suggestions? The hypervisor seems to call this `pfn_to_paddr'. Okay. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 11/17] xen/arm: ITS: Add GICR register emulation
On Mon, 2015-07-13 at 10:28 +0100, Ian Campbell wrote:
On Sat, 2015-07-11 at 20:25 +0200, Julien Grall wrote:
Hi,
On 10/07/2015 17:10, Ian Campbell wrote:
Extra space after the .
@@ -694,6 +755,14 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v,
mmio_info_t *info)
*r = ((ncpus - 1) GICD_TYPE_CPUS_SHIFT |
DIV_ROUND_UP(v-domain-arch.vgic.nr_spis, 32));
+if ( gic_lpi_supported() )
+{
+irq_bits = gic_nr_id_bits();
+*r |= GICD_TYPE_LPIS;
+}
+else
+irq_bits = get_count_order(vgic_num_irqs(v-domain));
I think gic_nr_id_bits should return the correct thing whether or not
LPIs are supported, i.e.
if ( gic_lpi_supported() )
*r |= GICD_TYPE_LPIS;
irq_bits = gic_nr_id_bits();
should be sufficient.
Well no. The field GICD_TYPER.IDbits represents the number of bits
supported for the interrupt identifier.
The guest may have a different number of IDbits than the hardware which
could be higher (for instance a guest where emulated SPI is supported).
Yes, I really meant vgic_nr_id_bits(), which might for the dom0 case end
up returning something related to the h/w value from the appropriate
vgic hw cfg struct.
Vijay, to be more specific, the number of idbits should be added to
xen/arch/arm/vgic-v3.c:vgic_v3_hw and as a new argument to
vgic_v3_setup_hw to initialise it.
Then vgic_v3_domain_init() should consult vgic_v3_hw in the
is_hardware_domain case to initialise a new field
d-arch.vgic.nr_id_bits.
For the !is_hardware_domain case I suppose it ought to be some hardcoded
value corresponding to whatever the right value is when LPIs are not
supported.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: avoid invalid phys_proc_id reference
On Mon, Jul 13, 2015 at 09:55:39AM +0100, Jan Beulich wrote: On 13.07.15 at 05:36, chao.p.p...@linux.intel.com wrote: phys_proc_id is invalidated in remove_siblinginfo() which gets called before cpu_smpboot_free(). This means calling cpu_to_socket(cpu) in cpu_smpboot_free() is not possible to be correct. This patch invokes remove_siblinginfo() in cpu_smpboot_free(), immediately after the use for cpu_to_socket(cpu). You having picked that variant of the two I proposed, did you verify that (as I said when talking about the alternative) there are no hidden dependencies? If you didn't, or if for whatever else reason there is any doubt, the less intrusive variant should be chosen at least for now. I just did some basic tests but I don't think I can conclude that I verified all the cases. Because of this, I'm glad to follow your advice to have a gentle fix. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: support for xen-access and email change
On Fri, 2015-07-10 at 16:39 +0100, Jan Beulich wrote: On 10.07.15 at 17:29, tleng...@novetta.com wrote: Add tools/tests/xen-acess to the supported list under VM EVENT/MEM ACCESS. Also, changing my e-mail to the preferred one, as it is in many of the headers already. Signed-off-by: Tamas K Lengyel tleng...@novetta.com It looks slightly odd to me that you sign off with you non-preferred mail address then... I don't think it is especially odd to want to receive patches via some path which offers proper filtering etc, but to still be obliged to S-o-b with the email associated with the entity which owns the rights to the contribution (but which uses an inflexible mail arrangement of some sort). Acked-by: Ian Campbell ian.campb...@citrix.com Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 07/17] xen/arm: ITS: Add virtual ITS commands support
On Mon, Jul 13, 2015 at 2:52 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Sat, 2015-07-11 at 20:19 +0530, Vijay Kilari wrote:
+int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
+{
+its_cmd_block virt_cmd;
+
+ASSERT(spin_is_locked(vits-lock));
+
+do {
+if ( vgic_its_read_virt_cmd(v, vits, virt_cmd) )
+goto err;
+if ( vgic_its_parse_its_command(v, vits, virt_cmd) )
+goto err;
+vgic_its_update_read_ptr(v, vits);
+} while ( vits-cmd_write != vits-cmd_write_save );
I can't find anywhere other than here where vits-cmd_write is touched.
What am I missing?
It is written by guest by GITS_CWRITER emulation in patch #9
Ah, then please reverse the order so that the variable comes first and
the target comes second.
Also I think you need to find a better name that cmd_write_save.
Something which indicates the progress made perhaps? But why isn't this
just cmd_read? Why the separate progress pointer?
I will check If I can use cmd_read.
BTW, I want to know if atomic_t supports 64-bit access?.
I have not made cmd_read as atomic_t.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 09/13] ts-debian-hvm-install: stub out libvirt + ovmf / rombios
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote:
Libvirt's configuration converter doesn't know how to deal with BIOS
selection. The end result is it always use the default one (seabios).
Stub out ovmf and rombios to avoid false positive results.
It's worth mentioning here whether or not we expect to currently see
such configurations in osstest today.
If we do expect to see them then it would be good to filter them in
make-flight to avoid wasting lots of test time.
This restriction will be removed once libvirt's converter knows how to
deal with BIOS selection.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
ts-debian-hvm-install | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index f05b1a7..bd16506 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,6 +28,13 @@ if (@ARGV $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1;
shift @ARGV; }
defined($r{bios}) or die Need to define which bios to use;
+# Libvirt doesn't know anything about bios. It will always use the
+# default one (seabios). Stub out rombios and ovmf to avoid false
+# positive results.
+if ($r{bios} =~ m/ovmf|rombios/ $r{toolstack} eq 'libvirt') {
+die libvirt + $r{bios} is not supported yet.;
+}
+
our ($whhost,$gn) = @ARGV;
$whhost ||= 'host';
$gn ||= 'debianhvm';
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 07/17] xen/arm: ITS: Add virtual ITS commands support
On Mon, 2015-07-13 at 16:45 +0530, Vijay Kilari wrote: BTW, I want to know if atomic_t supports 64-bit access?. I don't know off the top of my head. I'm sure it would be apparent in the code. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 09/28] tools/xl: Mandatory flag indicating the format of the migration stream
Introduced at this point so the python stream conversion code has a
concrete ABI to use. Later when libxl itself starts supporting a v2
stream, it will be added to XL_MANDATORY_FLAG_ALL.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v2: Expand commit message
---
tools/libxl/xl_cmdimpl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 971209c..26b1e7d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -109,6 +109,7 @@
*/
#define XL_MANDATORY_FLAG_JSON (1U 0) /* config data is in JSON format */
+#define XL_MANDATORY_FLAG_STREAMv2 (1U 1) /* stream is v2 */
#define XL_MANDATORY_FLAG_ALL (XL_MANDATORY_FLAG_JSON)
struct save_file_header {
char magic[32]; /* savefileheader_magic */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 06/28] tools/libxl: Split libxl__domain_create_state.restore_fd in two
In a future patch, we shall support automatically converting a legacy
stream to a v2 stream, in which case libxc needs to read from a
different fd.
Simply overwriting restore_fd does not work; the two fd's have
different circumstances. The restore_fd needs to be returned to its
original state before libxl_domain_create_restore() returns, while in
the converted case, the fd needs allocating and deallocating
appropriately.
No functional change.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
New in v2
---
tools/libxl/libxl_create.c |2 +-
tools/libxl/libxl_internal.h |2 +-
tools/libxl/libxl_save_callout.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 61515da..be13204 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1525,7 +1525,7 @@ static int do_domain_create(libxl_ctx *ctx,
libxl_domain_config *d_config,
cdcs-dcs.guest_config = d_config;
libxl_domain_config_init(cdcs-dcs.guest_config_saved);
libxl_domain_config_copy(ctx, cdcs-dcs.guest_config_saved, d_config);
-cdcs-dcs.restore_fd = restore_fd;
+cdcs-dcs.restore_fd = cdcs-dcs.libxc_fd = restore_fd;
if (restore_fd -1)
cdcs-dcs.restore_params = *params;
cdcs-dcs.callback = domain_create_cb;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6428757..e5599a3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3216,7 +3216,7 @@ struct libxl__domain_create_state {
libxl__ao *ao;
libxl_domain_config *guest_config;
libxl_domain_config guest_config_saved; /* vanilla config */
-int restore_fd;
+int restore_fd, libxc_fd;
libxl_domain_restore_params restore_params;
libxl__domain_create_cb *callback;
libxl_asyncprogress_how aop_console_how;
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 80aae1b..1136b79 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -48,7 +48,7 @@ void libxl__xc_domain_restore(libxl__egc *egc,
libxl__domain_create_state *dcs,
/* Convenience aliases */
const uint32_t domid = dcs-guest_domid;
-const int restore_fd = dcs-restore_fd;
+const int restore_fd = dcs-libxc_fd;
libxl__domain_build_state *const state = dcs-build_state;
unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 00/27] Libxl migration v2
This series adds support for the libxl migration v2 stream, and untangles the
existing layering violations of the toolstack and qemu records.
It can be found on the branch libxl-migv2-v3
git://xenbits.xen.org/people/andrewcoop/xen.git
http://xenbits.xen.org/git-http/people/andrewcoop/xen.git
No major changes over v2, but a lot of minor changes following review.
At the end of the series, legacy migration is no longer used.
The Remus code is untested by me. All other combinations of
suspend/migrate/resume have been tested with PV and HVM guests (qemu-trad and
qemu-upstream), including 32 - 64 bit migration (which was the underlying bug
causing us to write migration v2 in the first place).
Anyway, thoughts/comments welcome. Please test!
~Andrew
Summary of Acks/Modified/New from v2
A bsd-sys-queue-h-seddery: Massage `offsetof'
A tools/libxc: Always compile the compat qemu variables into xc_sr_context
A tools/libxl: Introduce ROUNDUP()
AM tools/libxl: Introduce libxl__kill()
A tools/libxl: Stash all restore parameters in domain_create_state
A tools/libxl: Split libxl__domain_create_state.restore_fd in two
M tools/libxl: Extra management APIs for the save helper
N tools/libxl: Add save_helper_state pointers to
libxl__xc_domain_{save,restore}()
A tools/xl: Mandatory flag indicating the format of the migration stream
A docs: Libxl migration v2 stream specification
A tools/python: Libxc migration v2 infrastructure
A tools/python: Libxl migration v2 infrastructure
A tools/python: Other migration infrastructure
A tools/python: Verification utility for v2 stream spec compliance
A tools/python: Conversion utility for legacy migration streams
A tools/libxl: Migration v2 stream format
M tools/libxl: Infrastructure for reading a libxl migration v2 stream
M tools/libxl: Infrastructure to convert a legacy stream
M tools/libxl: Convert a legacy stream if needed
M tools/libxc+libxl+xl: Restore v2 streams
M tools/libxl: Infrastructure for writing a v2 stream
M tools/libxc+libxl+xl: Save v2 streams
A docs/libxl: Introduce CHECKPOINT_END to support migration v2 remus streams
AM tools/libxl: Write checkpoint records into the stream
M tools/libx{c,l}: Introduce restore_callbacks.checkpoint()
M tools/libxl: Handle checkpoint records in a libxl migration v2 stream
A tools/libxc: Drop all XG_LIBXL_HVM_COMPAT code from libxc
A tools/libxl: Drop all knowledge of toolstack callbacks
Andrew Cooper (24):
tools/libxc: Always compile the compat qemu variables into xc_sr_context
tools/libxl: Introduce ROUNDUP()
tools/libxl: Introduce libxl__kill()
tools/libxl: Stash all restore parameters in domain_create_state
tools/libxl: Split libxl__domain_create_state.restore_fd in two
tools/libxl: Extra management APIs for the save helper
tools/libxl: Add save_helper_state pointers to
libxl__xc_domain_{save,restore}()
tools/xl: Mandatory flag indicating the format of the migration stream
docs: Libxl migration v2 stream specification
tools/python: Libxc migration v2 infrastructure
tools/python: Libxl migration v2 infrastructure
tools/python: Other migration infrastructure
tools/python: Verification utility for v2 stream spec compliance
tools/python: Conversion utility for legacy migration streams
tools/libxl: Infrastructure to convert a legacy stream
tools/libxl: Convert a legacy stream if needed
tools/libxc+libxl+xl: Restore v2 streams
tools/libxc+libxl+xl: Save v2 streams
docs/libxl: Introduce CHECKPOINT_END to support migration v2 remus streams
tools/libxl: Write checkpoint records into the stream
tools/libx{c,l}: Introduce restore_callbacks.checkpoint()
tools/libxl: Handle checkpoint records in a libxl migration v2 stream
tools/libxc: Drop all XG_LIBXL_HVM_COMPAT code from libxc
tools/libxl: Drop all knowledge of toolstack callbacks
Ian Jackson (1):
bsd-sys-queue-h-seddery: Massage `offsetof'
Ross Lagerwall (3):
tools/libxl: Migration v2 stream format
tools/libxl: Infrastructure for reading a libxl migration v2 stream
tools/libxl: Infrastructure for writing a v2 stream
docs/specs/libxl-migration-stream.pandoc | 217 ++
tools/include/xen-external/bsd-sys-queue-h-seddery |2 +
tools/libxc/Makefile |2 -
tools/libxc/include/xenguest.h |7 +
tools/libxc/xc_sr_common.h | 12 +-
tools/libxc/xc_sr_restore.c| 71 +-
tools/libxc/xc_sr_restore_x86_hvm.c| 124
tools/libxc/xc_sr_save_x86_hvm.c | 36 -
tools/libxl/Makefile |7 +
tools/libxl/libxl.h| 19 +
tools/libxl/libxl_aoutils.c| 15 +
tools/libxl/libxl_convert_callout.c| 158
tools/libxl/libxl_create.c | 91 ++-
tools/libxl/libxl_dom.c| 107
[Xen-devel] [PATCH v3 03/28] tools/libxl: Introduce ROUNDUP()
This is the same as is used by libxc.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_internal.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5235d25..19fc425 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -110,6 +110,9 @@
#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
+#define ROUNDUP(_val, _order) \
+(((unsigned long)(_val)+(1UL(_order))-1) ~((1UL(_order))-1))
+
#define min(X, Y) ({ \
const typeof (X) _x = (X); \
const typeof (Y) _y = (Y); \
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 07/28] tools/libxl: Extra management APIs for the save helper
With migration v2, there are several moving parts needing to be
juggled at once. This requires the error handling logic to be able to
query the state of each moving part, possibly before they have been
started, and be able to cancel them.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v3: Adjust helper_{stop,failed,done} to use libxl__save_helper_inuse()
v2: Add an _init() function which allows _inuse() to be safe to call even
before the save helper has started.
---
tools/libxl/libxl_create.c |1 +
tools/libxl/libxl_dom.c |1 +
tools/libxl/libxl_internal.h |9 +
tools/libxl/libxl_save_callout.c | 22 --
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index be13204..1f43b43 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -988,6 +988,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
rc = ERROR_INVAL;
goto out;
}
+libxl__save_helper_init(dcs-shs);
libxl__xc_domain_restore(egc, dcs,
hvm, pae, superpages);
return;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 8642192..63e2f47 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -2117,6 +2117,7 @@ void libxl__domain_suspend(libxl__egc *egc,
libxl__domain_suspend_state *dss)
callbacks-switch_qemu_logdirty =
libxl__domain_suspend_common_switch_qemu_logdirty;
dss-shs.callbacks.save.toolstack_save = libxl__toolstack_save;
+libxl__save_helper_init(dss-shs);
libxl__xc_domain_save(egc, dss);
return;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e5599a3..8ce3d49 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3272,6 +3272,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
int rc, int retval, int errnoval);
+_hidden void libxl__save_helper_init(libxl__save_helper_state *shs);
+_hidden void libxl__save_helper_abort(libxl__egc *egc,
+ libxl__save_helper_state *shs);
+
+static inline bool libxl__save_helper_inuse(const libxl__save_helper_state
*shs)
+{
+return libxl__ev_child_inuse(shs-child);
+}
+
/* Each time the dm needs to be saved, we must call suspend and then save */
_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
libxl__domain_suspend_state *dss);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1136b79..0fb1fdc 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -146,6 +146,13 @@ void
libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
shs-egc = 0;
}
+void libxl__save_helper_init(libxl__save_helper_state *shs)
+{
+libxl__ao_abortable_init(shs-abrt);
+libxl__ev_fd_init(shs-readable);
+libxl__ev_child_init(shs-child);
+}
+
/*- helper execution -*/
static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
@@ -167,9 +174,6 @@ static void run_helper(libxl__egc *egc,
libxl__save_helper_state *shs,
shs-rc = 0;
shs-completed = 0;
shs-pipes[0] = shs-pipes[1] = 0;
-libxl__ao_abortable_init(shs-abrt);
-libxl__ev_fd_init(shs-readable);
-libxl__ev_child_init(shs-child);
shs-abrt.ao = shs-ao;
shs-abrt.callback = helper_stop;
@@ -255,7 +259,7 @@ static void helper_failed(libxl__egc *egc,
libxl__save_helper_state *shs,
libxl__ev_fd_deregister(gc, shs-readable);
-if (!libxl__ev_child_inuse(shs-child)) {
+if (!libxl__save_helper_inuse(shs)) {
helper_done(egc, shs);
return;
}
@@ -268,7 +272,7 @@ static void helper_stop(libxl__egc *egc,
libxl__ao_abortable *abrt, int rc)
libxl__save_helper_state *shs = CONTAINER_OF(abrt, *shs, abrt);
STATE_AO_GC(shs-ao);
-if (!libxl__ev_child_inuse(shs-child)) {
+if (!libxl__save_helper_inuse(shs)) {
helper_failed(egc, shs, rc);
return;
}
@@ -279,6 +283,12 @@ static void helper_stop(libxl__egc *egc,
libxl__ao_abortable *abrt, int rc)
libxl__kill(gc, shs-child.pid, SIGTERM, save/restore helper);
}
+void libxl__save_helper_abort(libxl__egc *egc,
+ libxl__save_helper_state *shs)
+{
+helper_stop(egc, shs-abrt, ERROR_FAIL);
+}
+
static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
int fd, short events, short revents)
{
@@ -356,7 +366,7 @@ static void helper_done(libxl__egc *egc,
libxl__save_helper_state *shs)
libxl__ev_fd_deregister(gc, shs-readable);
[Xen-devel] [PATCH v3 01/28] bsd-sys-queue-h-seddery: Massage `offsetof'
From: Ian Jackson ian.jack...@eu.citrix.com For some reason BSD's queue.h uses `__offsetof'. It expects it to work just like offsetof. So use offsetof. Reported-by: Andrew Cooper andrew.coop...@citrix.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com --- tools/include/xen-external/bsd-sys-queue-h-seddery |2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/include/xen-external/bsd-sys-queue-h-seddery b/tools/include/xen-external/bsd-sys-queue-h-seddery index 7a957e3..3f8716d 100755 --- a/tools/include/xen-external/bsd-sys-queue-h-seddery +++ b/tools/include/xen-external/bsd-sys-queue-h-seddery @@ -69,4 +69,6 @@ s/\b struct \s+ type \b/type/xg; s,^\#include.*sys/cdefs.*,/* $ */,xg; +s,\b __offsetof \b ,offsetof,xg; + s/\b( NULL )/0/xg; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 04/28] tools/libxl: Introduce libxl__kill()
as a wrapper to kill(2), and use it in preference to sendsig in
libxl_save_callout.c.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
---
v3: Fix typo, add _hidden
Logically new in v2 - split out from a v1 change which was itself a
cherrypick-and-modify from the AO Abort series
---
tools/libxl/libxl_aoutils.c | 15 +++
tools/libxl/libxl_internal.h |2 ++
tools/libxl/libxl_save_callout.c | 10 ++
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 0931eee..274ef39 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -621,3 +621,18 @@ bool libxl__async_exec_inuse(const libxl__async_exec_state
*aes)
assert(time_inuse == child_inuse);
return child_inuse;
}
+
+void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what)
+{
+int r = kill(pid, sig);
+if (r) LOGE(WARN, failed to kill() %s [%lu] (signal %d),
+what, (unsigned long)pid, sig);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 19fc425..7ccbf55 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2244,6 +2244,8 @@ struct libxl__async_exec_state {
int libxl__async_exec_start(libxl__async_exec_state *aes);
bool libxl__async_exec_inuse(const libxl__async_exec_state *aes);
+_hidden void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what);
+
/*- device addition/removal -*/
typedef struct libxl__ao_device libxl__ao_device;
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 087c2d5..b82a5c1 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -244,12 +244,6 @@ static void run_helper(libxl__egc *egc,
libxl__save_helper_state *shs,
libxl__carefd_close(childs_pipes[1]);
helper_failed(egc, shs, rc);;
}
-static void sendsig(libxl__gc *gc, libxl__save_helper_state *shs, int sig)
-{
-int r = kill(shs-child.pid, sig);
-if (r) LOGE(WARN, failed to kill save/restore helper [%lu] (signal %d),
-(unsigned long)shs-child.pid, sig);
-}
static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
int rc)
@@ -266,7 +260,7 @@ static void helper_failed(libxl__egc *egc,
libxl__save_helper_state *shs,
return;
}
-sendsig(gc, shs, SIGKILL);
+libxl__kill(gc, shs-child.pid, SIGKILL, save/restore helper);
}
static void helper_stop(libxl__egc *egc, libxl__ao_abortable *abrt, int rc)
@@ -282,7 +276,7 @@ static void helper_stop(libxl__egc *egc,
libxl__ao_abortable *abrt, int rc)
if (!shs-rc)
shs-rc = rc;
-sendsig(gc, shs, SIGTERM);
+libxl__kill(gc, shs-child.pid, SIGTERM, save/restore helper);
}
static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 08/28] tools/libxl: Add save_helper_state pointers to libxl__xc_domain_{save, restore}()
Currently, libxl__xc_domain_{save,restore}() have specific knowledge
of where the libxl__save_helper_state lives inside a
libxl__domain_{create,save}_state object.
In later changes, the logical ownership of the
libxl__save_helper_state will change and will no longer be
d{c,s}s-shs.
No functional change.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
New in v3
---
tools/libxl/libxl_create.c |4 +--
tools/libxl/libxl_dom.c | 20 +++---
tools/libxl/libxl_internal.h |5 +++-
tools/libxl/libxl_save_callout.c | 54 --
4 files changed, 44 insertions(+), 39 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1f43b43..5d57bc3 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -989,7 +989,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
goto out;
}
libxl__save_helper_init(dcs-shs);
-libxl__xc_domain_restore(egc, dcs,
+libxl__xc_domain_restore(egc, dcs, dcs-shs,
hvm, pae, superpages);
return;
@@ -1001,7 +1001,7 @@ void libxl__srm_callout_callback_restore_results(unsigned
long store_mfn,
unsigned long console_mfn, void *user)
{
libxl__save_helper_state *shs = user;
-libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+libxl__domain_create_state *dcs = shs-caller_state;
STATE_AO_GC(dcs-ao);
libxl__domain_build_state *const state = dcs-build_state;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 63e2f47..9719837 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1121,7 +1121,7 @@ int libxl__toolstack_restore(uint32_t domid, const
uint8_t *ptr,
uint32_t size, void *user)
{
libxl__save_helper_state *shs = user;
-libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+libxl__domain_create_state *dcs = shs-caller_state;
STATE_AO_GC(dcs-ao);
int ret;
uint32_t version = 0, bufsize;
@@ -1188,7 +1188,7 @@ static void logdirty_init(libxl__logdirty_switch *lds)
libxl__save_helper_state *shs)
{
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
libxl__logdirty_switch *lds = dss-logdirty;
STATE_AO_GC(dss-ao);
int rc;
@@ -1260,7 +1260,7 @@ static void logdirty_init(libxl__logdirty_switch *lds)
libxl__save_helper_state *shs)
{
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
STATE_AO_GC(dss-ao);
int rc;
@@ -1279,7 +1279,7 @@ static void logdirty_init(libxl__logdirty_switch *lds)
{
libxl__save_helper_state *shs = user;
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
STATE_AO_GC(dss-ao);
switch (libxl__device_model_version_running(gc, domid)) {
@@ -1832,7 +1832,7 @@ static void libxl__domain_suspend_callback(void *data)
{
libxl__save_helper_state *shs = data;
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
dss-callback_common_done = domain_suspend_callback_common_done;
domain_suspend_callback_common(egc, dss);
@@ -1859,7 +1859,7 @@ static void libxl__remus_domain_suspend_callback(void
*data)
{
libxl__save_helper_state *shs = data;
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
dss-callback_common_done = remus_domain_suspend_callback_common_done;
domain_suspend_callback_common(egc, dss);
@@ -1902,7 +1902,7 @@ static void libxl__remus_domain_resume_callback(void
*data)
{
libxl__save_helper_state *shs = data;
libxl__egc *egc = shs-egc;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+libxl__domain_suspend_state *dss = shs-caller_state;
STATE_AO_GC(dss-ao);
libxl__remus_devices_state *const rds = dss-rds;
@@ -1947,8 +1947,8 @@ static void remus_next_checkpoint(libxl__egc *egc,
libxl__ev_time *ev,
static void libxl__remus_domain_checkpoint_callback(void *data)
{
libxl__save_helper_state *shs = data;
-libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
-libxl__egc *egc = dss-shs.egc;
+libxl__domain_suspend_state *dss = shs-caller_state;
+libxl__egc *egc = shs-egc;
STATE_AO_GC(dss-ao);
/* This would go into tailbuf. */
@@ -2118,7 +2118,7 @@ void
[Xen-devel] [PATCH v3 02/28] tools/libxc: Always compile the compat qemu variables into xc_sr_context
This is safe (as the variables will simply be unused), and is required for correct compilation when midway through untangling the libxc/libxl interaction. The #define is left in place to highlight that the variables can be removed once the untangling is complete. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- tools/libxc/xc_sr_common.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h index 565c5da..08c66db 100644 --- a/tools/libxc/xc_sr_common.h +++ b/tools/libxc/xc_sr_common.h @@ -307,10 +307,10 @@ struct xc_sr_context void *context; size_t contextsz; -#ifdef XG_LIBXL_HVM_COMPAT +/* #ifdef XG_LIBXL_HVM_COMPAT */ uint32_t qlen; void *qbuf; -#endif +/* #endif */ } restore; }; } x86_hvm; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 05/28] tools/libxl: Stash all restore parameters in domain_create_state
Shortly more parameters will appear, and this saves unboxing each one.
libxl_domain_restore_params is mandatory for restore streams, and
ignored for plain creation. The old 'checkpointed_stream' was
incorrectly identified as a private parameter when it was infact
public.
No functional change.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
Since v1:
* Gate validity on restore_fd being valid.
---
tools/libxl/libxl_create.c | 13 +++--
tools/libxl/libxl_internal.h |2 +-
tools/libxl/libxl_save_callout.c |2 +-
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b785ddd..61515da 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1512,8 +1512,8 @@ static void domain_create_cb(libxl__egc *egc,
int rc, uint32_t domid);
static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-uint32_t *domid,
-int restore_fd, int checkpointed_stream,
+uint32_t *domid, int restore_fd,
+const libxl_domain_restore_params *params,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
{
@@ -1526,8 +1526,9 @@ static int do_domain_create(libxl_ctx *ctx,
libxl_domain_config *d_config,
libxl_domain_config_init(cdcs-dcs.guest_config_saved);
libxl_domain_config_copy(ctx, cdcs-dcs.guest_config_saved, d_config);
cdcs-dcs.restore_fd = restore_fd;
+if (restore_fd -1)
+cdcs-dcs.restore_params = *params;
cdcs-dcs.callback = domain_create_cb;
-cdcs-dcs.checkpointed_stream = checkpointed_stream;
libxl__ao_progress_gethow(cdcs-dcs.aop_console_how, aop_console_how);
cdcs-domid_out = domid;
@@ -1553,7 +1554,7 @@ int libxl_domain_create_new(libxl_ctx *ctx,
libxl_domain_config *d_config,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
{
-return do_domain_create(ctx, d_config, domid, -1, 0,
+return do_domain_create(ctx, d_config, domid, -1, NULL,
ao_how, aop_console_how);
}
@@ -1563,8 +1564,8 @@ int libxl_domain_create_restore(libxl_ctx *ctx,
libxl_domain_config *d_config,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
{
-return do_domain_create(ctx, d_config, domid, restore_fd,
-params-checkpointed_stream, ao_how,
aop_console_how);
+return do_domain_create(ctx, d_config, domid, restore_fd, params,
+ao_how, aop_console_how);
}
/*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ccbf55..6428757 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3217,11 +3217,11 @@ struct libxl__domain_create_state {
libxl_domain_config *guest_config;
libxl_domain_config guest_config_saved; /* vanilla config */
int restore_fd;
+libxl_domain_restore_params restore_params;
libxl__domain_create_cb *callback;
libxl_asyncprogress_how aop_console_how;
/* private to domain_create */
int guest_domid;
-int checkpointed_stream;
libxl__domain_build_state build_state;
libxl__bootloader_state bl;
libxl__stub_dm_spawn_state dmss;
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index b82a5c1..80aae1b 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -60,7 +60,7 @@ void libxl__xc_domain_restore(libxl__egc *egc,
libxl__domain_create_state *dcs,
state-store_domid, state-console_port,
state-console_domid,
hvm, pae, superpages,
-cbflags, dcs-checkpointed_stream,
+cbflags, dcs-restore_params.checkpointed_stream,
};
dcs-shs.ao = ao;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 59485: regressions - trouble: broken/fail/pass
flight 59485 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/59485/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58965 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 3 host-install(3) broken pass in 59472 test-amd64-i386-xl-xsm3 host-install(3) broken pass in 59472 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3)broken pass in 59472 test-armhf-armhf-xl-credit2 13 guest-stop fail in 59472 pass in 59485 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 59472 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2 fail pass in 59472 test-amd64-amd64-xl-pvh-amd 9 debian-install fail pass in 59472 test-amd64-i386-xl6 xen-bootfail pass in 59472 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 59472 test-armhf-armhf-xl-arndale 9 debian-install fail pass in 59472 test-armhf-armhf-xl-cubietruck 9 debian-installfail pass in 59472 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 59472 like 58958 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 59472 like 58958 test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 58948 test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-start/debianhvm.repeat fail like 58948 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58965 test-armhf-armhf-xl-rtds 11 guest-start fail like 58965 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail in 59472 never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 59472 never pass test-armhf-armhf-xl 12 migrate-support-check fail in 59472 never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 59472 never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen 47b4d562b6a3441020fb6a7762603d1d3a74db27 baseline version: xen c40317f11b3f05e7c06a2213560c8471081f2662 Last test of basis58965 2015-06-29 02:08:30 Z 14 days Failing since 58974 2015-06-29 15:11:59 Z 13 days 15 attempts Testing same since59404 2015-07-10 21:58:25 Z2 days4 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Anthony PERARD anthony.per...@citrix.com Ard Biesheuvel a...@linaro.org Ben Catterall ben.catter...@citrix.com Boris Ostrovsky boris.ostrov...@oracle.com Chao Peng chao.p.p...@linux.intel.com Chen Baozi baoz...@gmail.com Daniel De Graaf dgde...@tycho.nsa.gov Dario Faggioli dario.faggi...@citrix.com David Scott dave.sc...@citrix.com Dietmar Hahn dietmar.h...@ts.fujitsu.com Euan Harris euan.har...@citrix.com Fabio Fantoni fabio.fant...@m2r.biz Feng Wu feng...@intel.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian,campb...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Jennifer Herbert jennifer.herb...@citrix.com Juergen Gross jgr...@suse.com Julien Grall julien.gr...@citrix.com Julien Grall julien.gr...@linaro.org Kevin Tian kevin.t...@intel.com Liang Li liang.z...@intel.com Paul Durrant paul.durr...@citrix.com Razvan Cojocaru rcojoc...@bitdefender.com Rob Hoes rob.h...@citrix.com Roger Pau Monné roger@citrix.com Samuel Thibault samuel.thiba...@ens-lyon.org Sander Eikelenboom li...@eikelenboom.it Tamas K Lengyel tleng...@novetta.com Thomas Leonard tal...@gmail.com Tiejun Chen
Re: [Xen-devel] Requesting for freeze exception for VT-d posted-interrupts
On 13.07.15 at 08:55, feng...@intel.com wrote: There are two main outstanding issues so far: 1. Jan's security concern. I have proposed some solutions but Jan still has some problems with my proposals. It would be great if Jan can give a clear proposal so that we can discuss and keep making progress. My proposal was quite clear: The functionality remains experimental, default off until you can come up with a satisfactory model here. Giving the impression that I'm the one to propose a model is simply inadequate: You want the functionality in, so it's primarily you who should find an implementation that's free of (latent) security issues. While in general other maintainers may help with this, implying that if they can't suggest a suitable model code with recognized potential for security problems can go in _and_ become supported is wrong. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
-Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:03 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)[82d080198b49] x86_emulate+0x56c9/0x13088 (XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281 (XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12 (XEN)[82d0801cb63e] handle_mmio+0x54/0xd2 (XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46 (XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d (XEN)[82d0801ee7d1] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back
Re: [Xen-devel] Question about mapping between domains
On Thu, 2015-07-09 at 16:31 +0300, Oleksandr Dmytryshyn wrote: I have some questions: 1. Is this a correct solution? 2. Could this solution be considered as a normal (not hack)? 3. If not then could anybody help me to implement this in the right way? The way we deal with this elsewhere in the kernel is that we only ever do grant mappings over ballooned out pages, which are allocated via gnttab_alloc_pages. That way when they are unmapped the page is expected to be entry and no backing mfn is lost. The page can then subsequently be ballooned back in as normal. There is an additional quirk for a 1:1 mapped dom0 which is that we don't actually decrease reservation when ballooning, but keep the 1:1 mfn in anticipation of ballooning it back in later. If you can't arrange to use already ballooned buffers for your DMA buffer then you will need to manually balloon it out before and balloon it back in later. You may also want to extend the dom0 1:1 quirk described above to your 1:1 mapped domD. If you have sufficient control over/knowledge of the domD IPA space then you could also try and arrange that the region used for these mappings does not correspond to any real RAM in the guest (i.e. stick it in an MMIO hole). That depends on you never needing to find an associated struct page though, which will depend on your use case. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 05/17] xen/arm: ITS: implement hw_irq_controller for LPIs
On Sat, 2015-07-11 at 20:10 +0530, Vijay Kilari wrote:
On Fri, Jul 10, 2015 at 7:16 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Fri, 2015-07-10 at 13:12 +0530, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Implements hw_irq_controller api's required
to handle LPI's
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Implement separate hw_irq_controller for LPIs
- Drop setting LPI affinity
- virq and vid are moved under union
- Introduced inv command handling
- its_device is stored in irq_desc
---
xen/arch/arm/gic-v3-its.c | 132
+
xen/arch/arm/gic-v3.c |5 +-
xen/arch/arm/gic.c| 32 +++--
xen/arch/arm/irq.c| 40 ++-
xen/include/asm-arm/gic-its.h |4 ++
xen/include/asm-arm/gic.h | 13
xen/include/asm-arm/gic_v3_defs.h |1 +
xen/include/asm-arm/irq.h |8 ++-
8 files changed, 227 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b421a6f..b98d396 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -295,6 +295,19 @@ post:
its_wait_for_range_completion(its, cmd, next_cmd);
}
+static void its_send_inv(struct its_device *dev, struct its_collection
*col,
+ u32 event_id)
+{
+its_cmd_block cmd;
+
+memset(cmd, 0x0, sizeof(its_cmd_block));
+cmd.inv.cmd = GITS_CMD_INV;
+cmd.inv.devid = dev-device_id;
+cmd.inv.event = event_id;
+
+its_send_single_command(dev-its, cmd, col);
+}
This ought to be in the prior patch doing such things I think.
Oh I see, you didn't have struct its_device defined back then. I think
you can just reorder patches #3 and #4 to solve that.
INV is used only in this patch in lpi_set_config().
So introduced in this patch
And the other patch introduces every (almost) every other cmd handler.
Having one patch do a bulk add of most commands and then other commands
dribbled in later as they are used just makes the series harder to
follow.
@@ -114,11 +137,12 @@ void gic_route_irq_to_xen(struct irq_desc *desc,
const cpumask_t *cpu_mask,
unsigned int priority)
{
ASSERT(priority = 0xff); /* Only 8 bits of priority */
-ASSERT(desc-irq gic_number_lines());/* Can't route interrupts that
don't exist */
+/* Can't route interrupts that don't exist */
+ASSERT(desc-irq gic_number_lines() || is_lpi(desc-irq));
As discussed in 1436284206.25646.258.ca...@citrix.com please make some
sort of is_valid_irq(irq) helper to encapsulate this logic.
I have added it patch#12. I remove this change from this patch
Please fix the ordering of the series so that you don't need to do
things like this. It just wastes review bandwidth since people reading
patch #5 have no idea what is going to happen in #12 and in any case bad
or redundant code shouldn't be added only to be removed later unless
there is really no option (a rare occurrence)
+unsigned int irq_to_vid(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-vid;
+}
+
+unsigned int irq_to_virq(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-virq;
+}
Please assert that irq_desc-arch.its_device is (non-)NULL as
appropriate in these two cases.
These two functions are accessing irq_guest structure not arch.its_device
-vid and -virq are members of a union. The distinguishing feature
which tells us which one is valid is whether or not
irq_desc-arch.its_device is NULL or not.
Therefore an assertion in each function should be added to catch cases
where people try to get the vid of an SPI or the virq of an LPI.
#define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
#define NR_GIC_SGI 16
+#define FIRST_GIC_LPI 8192
+#define NR_GIC_LPI 4096
+#define MAX_LPI(FIRST_GIC_LPI + NR_GIC_LPI)
MAX_LPI and NR_GIC_LPI should be obtained from the hardware at init time
and put somewhere, like a global nr_lpis perhaps, to be used throughout.
This MAX_LPI and NR_GIC_LPI is Xen limitation where in we
are allocating irq_descriptors statically upto NR_GIC_LPI.
As I said later on, please make this allocation dynamic as described in
the design doc. The static LPI descriptor array used in this series is
not acceptable.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 12:05 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 10:03 To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)[82d080198b49] x86_emulate+0x56c9/0x13088 (XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281 (XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12 (XEN)[82d0801cb63e] handle_mmio+0x54/0xd2 (XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46 (XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d (XEN)[82d0801ee7d1] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back enough to apply V4 on top of it (which has been thoroughly
Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters
On Mon, 2015-07-13 at 17:31 +0800, Chen, Tiejun wrote:
I still can't understand what I'm missing here after compared to other
contexts inside xlu_pci_parse_bdf().
Perhaps comparing to the CODING_STYLE document would help?
So I have to paste this entirely,
}else if ( !strcmp(optkey, rdm_policy) ) {
Should be:
} else if (!strcmp(optkey, rdm_policy)) {
i.e. space after } before else and no extra spaces inside the if
condition.
if ( !strcmp(tok, strict) ) {
if (!strcmp(tok, strict)) {
Again no spaces within the if.
pcidev-rdm_policy = LIBXL_RDM_RESERVE_POLICY_STRICT;
}else if ( !strcmp(tok, relaxed) ) {
Again add a space after } and remove those inside the if condition.
pcidev-rdm_policy =
LIBXL_RDM_RESERVE_POLICY_RELAXED;
}else{
Should be:
} else {
XLU__PCI_ERR(cfg, %s is not an valid PCI RDM
property
policy: 'strict' or
'relaxed'.,
tok);
goto parse_error;
}
}else{
and again } else {
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 13.07.15 at 11:30, paul.durr...@citrix.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 13 July 2015 10:28
To: Paul Durrant
Cc: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org; Keir
(Xen.org)
Subject: RE: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 13.07.15 at 11:05, paul.durr...@citrix.com wrote:
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
hvm_io_handle
{
struct hvm_hw_stdvga *s = current-domain-
arch.hvm_domain.stdvga;
+/*
+ * The range check must be done without taking any locks, to avoid
+ * deadlock when hvm_mmio_internal() is called from
+ * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
+ */
+if ( (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
+ (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE))
)
+return 0;
+
spin_lock(s-lock);
-if ( !s-stdvga ||
- (hvm_mmio_first_byte(p) VGA_MEM_BASE) ||
- (hvm_mmio_last_byte(p) = (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+if ( !s-stdvga )
goto reject;
if ( p-dir == IOREQ_WRITE p-count 1 )
But won't the problem continue to exist if the address falls within the
VGA range? I.e. isn't the problem that the two uses of
hvm_mmio_internal() are quite different - while
hvm_hap_nested_page_fault() immediately afterwards calls a
handle_mmio() variant (which would even seem to call for the lock not
getting dropped between them), __hvm_copy() uses it as just a check.
I.e. perhaps better to convert the lock to a recursive one?
I think we are ok because the stdvga model will never actually accept the
I/O since MMIO - MMIO rep mov is explicitly disallowed.
True, for now at least.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5 0/7] xen pvusb toolstack work
On 06/25/2015 12:07 PM, Chunyan Liu wrote: This patch series is to add pvusb toolstack work, supporting hot add|remove USB device to|from guest and specify USB device in domain configuration file. Patches 1-6: Tested-by: Juergen Gross jgr...@suse.com Juergen Changes to v4: * use DEFINE_DEVICE_ADD and DEFINE_DEVICES_ADD to handle usbctrl adding and usb adding, define extended macro DEFINE_DEVICE_REMOVE_EXT to handle usbctrl remove. * Change interfaces: libxl_device_usb only includes bus.addr, removing busid. 'xl usb-detach' uses ctrl,port to specify usb device instead of bus.addr. Adjusting all related codes. * Other changes addring all other comments in v4. V3 is here: http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html Related Discussion Threads: http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html pvusb work introduction 1. Overview There are two general methods for passing through individual host devices to a guest. The first is via an emulated USB device controller; the second is PVUSB. Additionally, there are two ways to add USB devices to a guest: via the config file at domain creation time, and via hot-plug while the VM is running. * Emulated USB In emulated USB, the device model (qemu) presents an emulated USB controller to the guest. The device model process then grabs control of the device from domain 0 and and passes the USB commands between the guest OS and the host USB device. This method is only available to HVM domains, and is not available for domains running with device model stubdomains. * PVUSB PVUSB uses a paravirtialized front-end/back-end interface, similar to the traditional Xen PV network and disk protocols. In order to use PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or your USB driver domain). 2. Specifying a host USB device QEMU qmp commands allows USB devices to be specified either by their bus address (in the form bus.device) or their device tag (in the form vendorid:deviceid). Each way of specifying has its advantages: Specifying by device tag will always get the same device, regardless of where the device ends up in the USB bus topology. However, if there are two identical devices, it will not allow you to specify which one. Specifying by bus address will always allow you to choose a specific device, even if you have duplicates. However, the bus address may change depending on which port you plugged the device into, and possibly also after a reboot. To avoid duplication of vendorid:deviceid, we'll use bus address to specify host USB device in xl toolstack. You can use lsusb to list the USB devices on the system: Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 003 Device 002: ID f617:0905 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra Fast Media Reader Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse To pass through the Logitec mouse, for instance, you could specify 1.6 (remove leading zeroes). Note: USB hubs can not be assigned to guest. 3. PVUSB toolstack * Specify USB device in xl config file You can just specify usb devices, like: usbdev=['1.6'] Then it will create a USB controller automatically and attach the USB device to the first available USB controller:port. or, you can explicitly specify usb controllers and usb devices, like: usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] usbdev=['1.6, controller=0, port=1'] Then it will create two USB controllers as you specified. And if controller and port are specified in usb config, then it will attach the USB device to that controller:port. About the controller and port value: Each USB controller has a index (or called devid) based on 0. The 1st controller has index 0, the 2nd controller has index 1, ... Under controller, each port has a port number based on 1. In above configuration, the 1st controller will have port 1,2,3,4. * Hot-Plug USB device To attach a USB device, you should first create a USB controller. e.g. xl usb-ctrl-attach domain [version=1|2] [ports=value] By default, it will create a USB2.0 controller with 8 ports. Then you could attach a USB device. e.g. xl usb-attach domain 1.6 [controller=index port=number] By default, it will find the 1st available controller:port to attach the USB device. You could view USB device status of the domain by usb-list. e.g. xl usb-list domain It will list USB controllers and USB devices under each controller. You could detach a USB device with usb-detach command. e.g. xl usb-detach domain 1.6 You can also remove the whole USB controller by usb-ctrl-detach command. e.g. xl usb-ctrl-detach domain 0 It will remove the USB controller with index 0 and all USB devices
Re: [Xen-devel] [PATCH V5 7/7] domcreate: support pvusb in configuration file
On 06/25/2015 12:07 PM, Chunyan Liu wrote: Add code to support pvusb in domain config file. One could specify usbctrl and usb in domain's configuration file and create domain, then usb controllers will be created and usb device would be attached to guest automatically. One could specify usb controllers and usb devices in config file like this: usbctrl=['version=2,ports=4', 'version=1,ports=4', ] usbdev=['2.1,controller=0,port=1', ] Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com I tested this patch and it still isn't working: config file: usbctrl = [ 'version=2,ports=4', ] usbdev = [ '3.4,controller=0,port=1', ] xl create output: xl: libxl_event.c:1759: libxl__ao_inprogress_gc: Assertion `!ao-complete' failed. I'm not sure, but comparing e.g. libxl__device_disk_add() with libxl__device_usb_add() shows a significant difference regarding passing of ao data. I think you'll need a wrapper as in the disk case and pass NULL for ao to the attach function being capable of async operation when you are calling the attach function during domain creation. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/9] libxl: localtime(3) can return NULL
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote: Signed-off-by: Wei Liu wei.l...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Requesting for freeze exception for VT-d posted-interrupts
On Mon, Jul 13, 2015 at 06:55:30AM +, Wu, Feng wrote: Hi maintainers, We would like to request an extension for freeze exception for VT-d posted-interrupts patch-set. 1. clarify the state of patch series / feature. [v3 01/15] Vt-d Posted-interrupt (PI) design Reviewed-by: Kevin Tian kevin.t...@intel.com [v3 02/15] Add helper macro for X86_FEATURE_CX16 feature detection Reviewed-by: Kevin Tian kevin.t...@intel.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com [v3 04/15] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature Reviewed-by: Kevin Tian kevin.t...@intel.com [v3 06/15] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts Reviewed-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Kevin Tian kevin.t...@intel.com [v3 07/15] vmx: Initialize VT-d Posted-Interrupts Descriptor Acked-by: Kevin Tian kevin.t...@intel.com [v3 09/15] vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts Acked-by: Kevin Tian kevin.t...@intel.com [v3 10/15] vt-d: Add API to update IRTE when VT-d PI is used Acked-by: Kevin Tian kevin.t...@intel.com [v3 13/15] vmx: Properly handle notification event when vCPU is running Acked-by: Kevin Tian kevin.t...@intel.com [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Acked-by: Kevin Tian kevin.t...@intel.com [v3 15/15] Add a command line parameter for VT-d posted-interrupts Reviewed-by: Kevin Tian kevin.t...@intel.com 2. explain why it needs to be in this release (benefits). VT-d posted-interrupts is an important interrupt virtualization feature for device pass-through, the running guest can handle external interrupts in non-root mode, hence it can eliminate the VM-Exits caused by external interrupts. Please refer to the design doc: http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03691.html From our experimental environment, after using VT-d posted-interrupts, we measured 25% improvement in transaction rate netperf TCP_RR benchmark and 28% reduction in host CPU utilization when using assigned devices. (10G NIC in my test). 3. explain why it doesn't break things (risks). This feature only exists in Broadwell Server platform, it has no effect on the current hardware. You miss the part that how much common code it touches. There is still risk of breaking VMX and VT-D even if PI is disabled. 4. CC relevant maintainers and release manager. Done There are two main outstanding issues so far: 1. Jan's security concern. I have proposed some solutions but Jan still has some problems with my proposals. It would be great if Jan can give a clear proposal so that we can discuss and keep making progress. 2. Scheduler issue: there are conflicts among maintainers Jan/George/Dario. I would agree with Jan's suggestion below: Doing this in a central place is certainly the right approach, but adding an arch hook that needs to be called everywhere vcpu_runstate_change() wouldn't serve that purpose. Instead we'd need to replace all current vcpu_runstate_change() calls with calls to a new function calling both this and the to be added arch hook. Given the current time scale now, I think it would be very hard to get these two concerns addressed within a week. Xen has always taken security serious, I don't want to rush in a feature with possible flawed design. My answer to this request is no until these concerns are addressed. However, if different maintainers still hold different opinions, I would appreciate it if maintainers can reach consensus among themselves so that we can keep making progress Yes, this is fore sure. This is what we need to do to work as a community whether this feature is aimed for 4.6 or not. Wei. Thanks, Feng ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/hvm: add support for broadcast of buffered ioreqs...
On 10.07.15 at 18:07, paul.durr...@citrix.com wrote:
@@ -2710,17 +2711,21 @@ int hvm_send_assist_req(struct hvm_ioreq_server *s,
ioreq_t *proto_p)
return X86EMUL_UNHANDLEABLE;
}
-void hvm_broadcast_assist_req(ioreq_t *p)
+int hvm_broadcast_ioreq(ioreq_t *p, bool_t buffered)
{
struct domain *d = current-domain;
struct hvm_ioreq_server *s;
+unsigned int failed = 0;
ASSERT(p-type == IOREQ_TYPE_INVALIDATE);
list_for_each_entry ( s,
d-arch.hvm_domain.ioreq_server.list,
list_entry )
-(void) hvm_send_assist_req(s, p);
+if ( hvm_send_ioreq(s, p, buffered) == X86EMUL_UNHANDLEABLE )
+failed++;
+
+return failed;
I'll try to remember fixing up the mismatch between function return
type and return expression upon commit. Looks good beyond that.
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 05/11] xen: grant_table: implement grant_table_warn_active_grants()
On 10.07.15 at 18:24, konrad.w...@oracle.com wrote: On Tue, Jun 23, 2015 at 06:11:47PM +0200, Vitaly Kuznetsov wrote: Log first 10 active grants of a domain. This function is going to be used for soft reset, active grants on this path usually mean misbehaving backends refusing to release their mappings on shutdown. Is there an particular reason 10 was choosen instead of 42 for example :-) Also the 10 should probably have an #define for it. Or even be command line controllable. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 12:01 PM, Paul Durrant wrote: -Original Message- From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] Sent: 13 July 2015 09:50 To: Andrew Cooper; xen-devel@lists.xen.org Cc: Keir (Xen.org); Jan Beulich; Paul Durrant Subject: Re: Deadlock in stdvga_mem_accept() with emulation On 07/13/2015 11:10 AM, Andrew Cooper wrote: On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[82d08012c3f1] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[82d08012c3f1] _spin_lock+0x31/0x54 (XEN)[82d0801d09b6] stdvga_mem_accept+0x3b/0x125 (XEN)[82d0801cb23a] hvm_find_io_handler+0x68/0x8a (XEN)[82d0801cb410] hvm_mmio_internal+0x37/0x67 (XEN)[82d0801c2403] __hvm_copy+0xe9/0x37d (XEN)[82d0801c3e5d] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[82d0801cb107] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[82d0801cb291] hvm_io_intercept+0x35/0x5b (XEN)[82d0801bb440] hvmemul_do_io+0x1ff/0x2c1 (XEN)[82d0801bc0b9] hvmemul_do_io_addr+0x117/0x163 (XEN)[82d0801bc129] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[82d0801bcbb5] hvmemul_rep_movs+0x1ef/0x335 (XEN)[82d080198b49] x86_emulate+0x56c9/0x13088 (XEN)[82d0801bbd26] _hvm_emulate_one+0x186/0x281 (XEN)[82d0801bc1e8] hvm_emulate_one+0x10/0x12 (XEN)[82d0801cb63e] handle_mmio+0x54/0xd2 (XEN)[82d0801cb700] handle_mmio_with_translation+0x44/0x46 (XEN)[82d0801c27f6] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[82d0801e9741] vmx_vmexit_handler+0x150e/0x188d (XEN)[82d0801ee7d1] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back enough to apply V4 on top of it (which has been thoroughly tested on Thursday), and it still happens, so this would at least appear to be unrelated at this point (other than the fact that our use case is maybe somewhat unusual with heavy emulation). I'll keep digging, but since this is a busy time for Xen I thought I'd issue a heads-up here as soon as possible, in case the problem
Re: [Xen-devel] [PATCH v4 07/17] xen/arm: ITS: Add virtual ITS commands support
On Sat, 2015-07-11 at 20:19 +0530, Vijay Kilari wrote:
+int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
+{
+its_cmd_block virt_cmd;
+
+ASSERT(spin_is_locked(vits-lock));
+
+do {
+if ( vgic_its_read_virt_cmd(v, vits, virt_cmd) )
+goto err;
+if ( vgic_its_parse_its_command(v, vits, virt_cmd) )
+goto err;
+vgic_its_update_read_ptr(v, vits);
+} while ( vits-cmd_write != vits-cmd_write_save );
I can't find anywhere other than here where vits-cmd_write is touched.
What am I missing?
It is written by guest by GITS_CWRITER emulation in patch #9
Ah, then please reverse the order so that the variable comes first and
the target comes second.
Also I think you need to find a better name that cmd_write_save.
Something which indicates the progress made perhaps? But why isn't this
just cmd_read? Why the separate progress pointer?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Interested in taking up a project
On Sat, 2015-07-11 at 02:03 +0530, Abhinav Gupta wrote: Hi everyone, Hey, :-) I'm sorry for the late update. Actually I had another project going on in parallel, didn't want to distribute efforts. Sure, no problem. I went through the implementation approach of powerclamp, it controls power consumption by managing C states of the core. This was my learning so far. Code makes a little sense to me, I'll need some more time to get hands on powerclamp's code ( I'hv no experience with linux kernel code). After this I'll start exploring Xen. Right. Bear in mind that, with respect to this, Linux and Xen are quite different. Or at least, that's certainly true for scheduling... for ACPI, there might be similarities due to the fact that ACPI support in Xen is inspired to Linux one, but I'm no expert in that, so I don't really know. The point I wanted to make was, although some understanding on how things work in Linux, in order to figure out what PowerClamp really does, is necessary, start focusing on Xen ASAP, as that is your target! :-) @Dario I'll look into how popular it is in the linux world and if there are some real popular real space applications built on top of it. I'll put my findings here. Ok, that would be great. 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 RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/9] libxl: avoid leaking string in cpupool_info
On Fri, 2015-07-10 at 19:00 +0100, Wei Liu wrote:
Signed-off-by: Wei Liu wei.l...@citrix.com
Would an if (rc) libxl_cpupoolinfo_dispose(info) on the exit path be a
more robust alternative? Might require the addition of a
libxl_cpupoolinfo_init() somewhere before any possible error.
---
tools/libxl/libxl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 38aff8d..4151dcb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -740,8 +740,10 @@ static int cpupool_info(libxl__gc *gc,
info-sched = xcinfo-sched_id;
info-n_dom = xcinfo-n_dom;
rc = libxl_cpu_bitmap_alloc(CTX, info-cpumap, 0);
-if (rc)
+if (rc) {
+free(info-pool_name);
goto out;
+}
memcpy(info-cpumap.map, xcinfo-cpumap, info-cpumap.size);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59472: regressions - FAIL
On 13.07.15 at 03:43, osstest-ad...@xenproject.org wrote: flight 59472 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/59472/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 Considering (on italia1) Jul 12 21:27:20.505103 (d1) No bootable device. Jul 12 21:27:20.505128 (d1) Powering off in 30 seconds. is this really a regression (rather than something that never fully worked)? With flight 58917 also having (on chardonnay0) Jun 27 11:08:08.025161 (d1) No bootable device. Jun 27 11:08:08.033014 (d1) Powering off in 30 seconds. is it possible that 58965's success (on elbling1) was because this only works on a very limited subset of hosts? I didn't spot anything in the logs of the failure cases that would help me understand the reason for the failures... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86: avoid invalid phys_proc_id reference
phys_proc_id is invalidated in remove_siblinginfo() which gets called
before cpu_smpboot_free(). This means calling cpu_to_socket(cpu) in
cpu_smpboot_free() is not possible to be correct.
This patch moves the invalidating of phys_proc_id from
remove_siblinginfo() to cpu_smpboot_free() so that cpu_to_socket(cpu)
can be used in cpu_smpboot_free().
The same is done for cpu_core_id/compute_unit_id and due to that
cpu_sibling_setup_map is private to the file so it's moved as well.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Suggested-by: Jan Beulich jbeul...@suse.com
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
---
v2: use less intrusive solution.
---
xen/arch/x86/smpboot.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0f03364..8b292c0 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -666,6 +666,7 @@ void cpu_exit_clear(unsigned int cpu)
static void cpu_smpboot_free(unsigned int cpu)
{
unsigned int order, socket = cpu_to_socket(cpu);
+struct cpuinfo_x86 *c = cpu_data;
if ( cpumask_empty(socket_cpumask[socket]) )
{
@@ -673,6 +674,11 @@ static void cpu_smpboot_free(unsigned int cpu)
socket_cpumask[socket] = NULL;
}
+c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
+c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
+c[cpu].compute_unit_id = INVALID_CUID;
+cpumask_clear_cpu(cpu, cpu_sibling_setup_map);
+
free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
free_cpumask_var(per_cpu(cpu_core_mask, cpu));
@@ -882,7 +888,6 @@ static void
remove_siblinginfo(int cpu)
{
int sibling;
-struct cpuinfo_x86 *c = cpu_data;
cpumask_clear_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]);
@@ -891,17 +896,13 @@ remove_siblinginfo(int cpu)
cpumask_clear_cpu(cpu, per_cpu(cpu_core_mask, sibling));
/* Last thread sibling in this cpu core going down. */
if ( cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) == 1 )
-c[sibling].booted_cores--;
+cpu_data[sibling].booted_cores--;
}
for_each_cpu(sibling, per_cpu(cpu_sibling_mask, cpu))
cpumask_clear_cpu(cpu, per_cpu(cpu_sibling_mask, sibling));
cpumask_clear(per_cpu(cpu_sibling_mask, cpu));
cpumask_clear(per_cpu(cpu_core_mask, cpu));
-c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
-c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
-c[cpu].compute_unit_id = INVALID_CUID;
-cpumask_clear_cpu(cpu, cpu_sibling_setup_map);
}
void __cpu_disable(void)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 08/13] ts-libvirt-build: run libvirt test suite
On Sun, 2015-07-12 at 17:20 +0100, Wei Liu wrote: We're interested in xlconfigtest. Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com [...] + | tee ../libvirt-test-suite-log Should something be collecting/stashing that log file? I think since it is logged to the output of the command it's probably not needed, but I suppose you added the tee for a reason? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
