-Original Message-
From: Grub-devel
[mailto:grub-devel-bounces+wojciech.m.szyfelbein=intel@gnu.org] On Behalf
Of Daniel Kiper
Sent: Thursday, November 30, 2017 10:23 PM
To: Julien Grall
Cc: grub-de...@gnu.org; fu@linaro.org; xen-de...@lists.xen.org
Subject: Re: [PATCH] arm64/xe
>>> On 01.12.17 at 19:45, wrote:
> On 28/11/17 08:32, Jan Beulich wrote:
> On 26.10.17 at 19:03, wrote:
>>> * invvpid has a 128-bit memory operand but we only require the VPID value
>>> which lies in the lower 64 bits.
>> The memory operand (wrongly) isn't being read at all - I don't
>> und
>>> On 01.12.17 at 16:31, wrote:
> On 30/11/17 14:31, Jan Beulich wrote:
>> Jann validly points out that with a caller bogusly requesting a zero-
>> element batch with non-zero high command bits (the ones used for
>> continuation encoding), the assertion right before the call to
>> hypercall_creat
>>> On 01.12.17 at 16:31, wrote:
> On 30/11/17 14:32, Jan Beulich wrote:
>> Dropping the lock before returning from grant_map_exists() means handing
>> possibly stale information back to the caller. Return back the pointer
>> to the active entry instead, for the caller to release the lock once
>>
flight 116799 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116799/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 116625
Tests
Dear all,
I am trying to write a sample program to share a memory between two domains
using grant table mechanism. I have found some api's like
gnttab_grant_foreign_access_ref, xengnttab_map_domain_grant_refs etc. But I
have no idea of using it. I have searched but I couldn't find any guidance
rega
>>> On 01.12.17 at 22:38, wrote:
> On Thu, 30 Nov 2017, Jan Beulich wrote:
>> Jann validly points out that with a caller bogusly requesting a zero-
>> element batch with non-zero high command bits (the ones used for
>> continuation encoding), the assertion right before the call to
>> hypercall_cre
>>> On 23.11.17 at 16:09, wrote:
> There were two issues with this function: Its use of
> hvmemul_do_pio_buffer() was wrong (the function deals only with
> individual port accesses, not repeated ones, i.e. passing it
> "*reps * bytes_per_rep" does not have the intended effect). And it
> could have
>>> On 03.07.17 at 16:56, wrote:
On 31.05.17 at 13:54, wrote:
> On 31.05.17 at 13:08, wrote:
> > > On 31/05/17 08:15, Jan Beulich wrote:
> > >> The flag is really only meant for those, both HVM and 32-bit PV tell
> > >> kernel from user mode based on CPL/RPL. Remove the all-question-ma
Signed-off-by: Daniel Kiper
---
xen/common/efi/boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 01d3300..469bf98 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -176,7 +176,7 @@ static void __init _
>>> On 25.08.17 at 16:59, wrote:
On 10.08.17 at 09:19, wrote:
> On 10.07.17 at 12:39, wrote:
> >> Real hardware wraps silently in most cases, so we should behave the
> >> same. Also split real and VM86 mode handling, as the latter really
> >> ought to have limit checks applied.
> >>
>
These were held back due to the freeze.
1: x86/IRQ: conditionally preserve access permission on map error paths
2: x86/MSI: leverage local variables
3: XSM/flask: constification of IRQ mapping interfaces
Signed-off-by: Jan Beulich
___
Xen-devel maili
Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
(x86: make Xen early boot code relocatable) is not reliable. Potentially
its value may fall below PFN_DOWN(__pa(_end)) and then part of Xen image
may not be mapped after relocation. This will not happen in current code
thanks to
Hi,
As in subject... This is extended version of fix posted earlier as "x86/setup:
do not relocate below the end of current Xen image placement".
Daniel
xen/arch/x86/setup.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
Daniel Kiper (3):
x86/crash
Commit e22e1c4 (x86/EFI: avoid Xen image when looking for module/kexec
position) added relevant check for EFI case. However, since commit
f75a304 (x86: add multiboot2 protocol support for relocatable images)
Multiboot2 compatible bootloaders are able to relocate Xen image too.
So, we have to avoid
Otherwise, due to Xen code/data changes under CPU feet, Xen may crash
silently at boot.
We were hit by the issue in OVS Xen 4.4 with my earlier version of
EFI/Multiboot2 patches. Initially its implementation allowed relocation
of Xen even if it was relocated by the bootloader. This led to the
cras
I'm not sure why we had left out the address check in case of indirect
accesses (where "data" holds a guest physical address).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -163,7 +163,8 @@ static int hvmemul_do_io(
(p.count > *reps
Permissions that had been granted before should not be revoked when
handling unrelated errors.
Reported-by: HW42
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1918,6 +1918,7 @@ int map_domain_pirq(
struct irq_desc *desc;
unsigned long flags;
DEC
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2017 10:13
> To: Paul Durrant
> Cc: Razvan Cojocaru ; xen-devel de...@lists.xenproject.org>
> Subject: Ping: [PATCH] x86/HVM: fix hvmemul_rep_outs_set_context()
>
> >>> On 23.11.17 at 16:09, wrote:
>
... instead of using redundant calculations.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -446,8 +446,7 @@ static bool msi_set_mask_bit(struct irq_
pdev->msix->warned = domid;
printk(XENLOG_G_WARNING
"ca
This clarifies that the involved structures are read-only.
Signed-off-by: Jan Beulich
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -445,7 +445,8 @@ static XSM_INLINE int xsm_map_domain_pir
return xsm_default_action(action, current->domain, d);
}
-static XSM_INLINE int x
These were held back due to the freeze.
1: make get_page_from_mfn() return struct page_info *
2: remove _PAGE_PSE check from get_page_from_l2e()
3: improve _put_page_type() readability
4: use switch() in _put_page_type()
5: make _get_page_type() a proper counterpart of _put_page_type() again
Sign
>>> On 04.12.17 at 11:15, wrote:
> Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2017 10:26
> To: xen-devel
> Cc: Paul Durrant
> Subject: [PATCH] x86/HVM: tighten re-issue check in hvmemul_do_io()
>
> I'm not sure why we had left out the address check in case of indirect
> accesse
>>> On 12.10.17 at 14:24, wrote:
> Silently assuming DOMID_SELF is unlikely to be a good idea for page
> table updates. For PGT_writable pages, though, it seems better to allow
> the writes, so the same check isn't being applied there.
>
> Also add blank lines between the individual case blocks.
>>> On 12.10.17 at 12:01, wrote:
> Don't accept anything other than r/w RAM pages and move the paged-out
> check into the (unlikely) error path following that check.
>
> Signed-off-by: Jan Beulich
Ping?
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3507,18 +3507,18 @@ long do_mmu_u
Almost all users of it want it, and it calculates it anyway.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -704,7 +704,6 @@ get_##level##_linear_pagetable(
level##_pgentry_t pde, unsigned long pde_pfn, struct domain *d) \
{
With L2_DISALLOW_MASK containing _PAGE_PSE unconditionally as of commit
56fff3e5e9 ("x86: nuke PV superpage option and code") there's no point
anymore in separately checking for the bit.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1106,15 +1106,10 @@ get_page_f
By limiting the scope of rc it is more obvious that failure can be
reported only if _put_final_page_type() failed.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2452,7 +2452,6 @@ static int _put_page_type(struct page_in
struct page_info
Use this to cheaply add another assertion.
Signed-off-by: Jan Beulich
---
TBD: Would it perhaps be better to return after the assertion?
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2460,8 +2460,9 @@ static int _put_page_type(struct page_in
ASSERT((x & PGT_count_mask) != 0);
Drop one of the leading underscores and use bool for its "preemptible"
parameter.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2531,8 +2531,8 @@ static int _put_page_type(struct page_in
}
-static int __get_page_type(struct page_info *page, unsigned long typ
1: PoD: correctly handle non-order-0 decrease-reservation requests
2: mm: drop yet another relic of translated PV domains from new_guest_cr3()
3: p2m: force return value checking of p2m_set_entry()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
The function can be called for PV domains only, which commit 5a0b9fba92
("x86/mm: drop further relics of translated PV domains") sort of
realized, but not fully.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2846,9 +2846,7 @@ int new_guest_cr3(mfn_t mfn)
p2m_pod_decrease_reservation() returning just (not) all-done is not
sufficient for the caller: If some pages were processed,
guest_remove_page() returning an error for those pages is the expected
result rather than an indication of a problem. Make guest_remove_page()
return a distinct error code fo
As XSAs 246 and 247 have shown, not doing so is rather dangerous.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1550,9 +1550,11 @@ void p2m_mem_paging_populate(struct doma
if ( p2mt == p2m_ram_paging_out )
req.u.mem_paging.flags |= M
On 11/30/2017 02:31 PM, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A s
Hello,
I am not sure to understand why I am being CCed. But it looks like you
CC everyone on each patch... Please CC only relevant person on each patch.
Cheers,
On 04/12/17 00:15, Boqun Feng wrote:
From: Kai Huang
Expose SGX in CPU featureset for HVM domain. SGX will not be supported for
P
>>> On 04.12.17 at 12:12, wrote:
> On 11/30/2017 02:31 PM, Jan Beulich wrote:
>> Jann validly points out that with a caller bogusly requesting a zero-
>> element batch with non-zero high command bits (the ones used for
>> continuation encoding), the assertion right before the call to
>> hypercall_
On 12/04/2017 09:02 AM, Jan Beulich wrote:
On 01.12.17 at 16:31, wrote:
>> On 30/11/17 14:32, Jan Beulich wrote:
>>> Dropping the lock before returning from grant_map_exists() means handing
>>> possibly stale information back to the caller. Return back the pointer
>>> to the active entry inst
>>> On 04.12.17 at 12:31, wrote:
> On 12/04/2017 09:02 AM, Jan Beulich wrote:
> On 01.12.17 at 16:31, wrote:
>>> On 30/11/17 14:32, Jan Beulich wrote:
Dropping the lock before returning from grant_map_exists() means handing
possibly stale information back to the caller. Return back
This run is configured for baseline tests only.
flight 72513 qemu-upstream-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd6
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xe
Hi,
> And the most important question is how to recognize in Xen on ARM
> (using SCPI protocol) which frequencies are turbo-frequencies
> actually? I couldn't find any information regarding that in protocol
> description.
So traditionally on ARM there is no notion of a "turbo" frequency. Th
At least Linux kernels have been able to work with gzip-ed initrd for
quite some time; initrd compressed with other methods aren't even being
attempted to unpack. Furthermore the unzip-ing routine used here isn't
capable of dealing with various forms of concatenated files, each of
which was gzip-ed
On Mon, Dec 04, 2017 at 11:13:45AM +, Julien Grall wrote:
> Hello,
>
Hi Julien,
> I am not sure to understand why I am being CCed. But it looks like you CC
> everyone on each patch... Please CC only relevant person on each patch.
>
Apologies... I thought the whole pathset will provide mor
flight 116828 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116828/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116809 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 116744
Tests which are fa
>>> On 04.12.17 at 14:10, wrote:
> On Mon, Dec 04, 2017 at 11:13:45AM +, Julien Grall wrote:
>> I am not sure to understand why I am being CCed. But it looks like you CC
>> everyone on each patch... Please CC only relevant person on each patch.
>>
>
> Apologies... I thought the whole pathse
Hi,
I am going to answer both e-mails (Stefano and Volodymyr) at once.
On 01/12/17 22:58, Stefano Stabellini wrote:
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
This is follow-up to our conversation during community call.
You asked me to send OP-TEE mediator as a patch, so we can
discuss it i
On 01/12/17 22:58, Stefano Stabellini wrote:
>
> = Xen command forwarding =
>
> In the code below, it looks like Xen is forwarding everything to OP-TEE.
> Are there some commands Xen should avoid forwarding? Should we have a
> whitelist or a blacklist?
Whitelist everything.
At the very minimum, i
On Mon, Dec 4, 2017 at 3:40 AM, m...@ark-net.org wrote:
> So I figured out that I don't need a running instance of xenstored on the
> driver domain, since xenstore-read works for the driver domains own trees in
> xenstore. Are the xenstore-read errors in vif-openvswitch because that
> script is w
On 04/12/17 10:15, Jan Beulich wrote:
On 03.07.17 at 16:56, wrote:
> On 31.05.17 at 13:54, wrote:
>> On 31.05.17 at 13:08, wrote:
On 31/05/17 08:15, Jan Beulich wrote:
> The flag is really only meant for those, both HVM and 32-bit PV tell
> kernel from user mode based o
On 04/12/17 10:44, Jan Beulich wrote:
> Almost all users of it want it, and it calculates it anyway.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
On 04/12/17 10:44, Jan Beulich wrote:
> With L2_DISALLOW_MASK containing _PAGE_PSE unconditionally as of commit
> 56fff3e5e9 ("x86: nuke PV superpage option and code") there's no point
> anymore in separately checking for the bit.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm.c
> +++ b/
On 04/12/17 10:45, Jan Beulich wrote:
> @@ -2477,10 +2478,9 @@ static int _put_page_type(struct page_in
> continue;
> /* We cleared the 'valid bit' so we do the clean up. */
> rc = _put_final_page_type(page, x, preemptible, ptpg);
> -
On 12/04/2017 05:34 AM, Jan Beulich wrote:
This clarifies that the involved structures are read-only.
Signed-off-by: Jan Beulich
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
On 04/12/17 10:46, Jan Beulich wrote:
> Use this to cheaply add another assertion.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: Would it perhaps be better to return after the assertion?
Yes, otherwise we risk falling into an infinite continue loop.
With a suitable return value, Reviewed-by: Andre
On 04/12/17 10:46, Jan Beulich wrote:
> @@ -2709,7 +2710,7 @@ int put_page_type_preemptible(struct pag
> int get_page_type_preemptible(struct page_info *page, unsigned long type)
> {
> ASSERT(!current->arch.old_guest_table);
Newline. Otherwise, Reviewed-by: Andrew Cooper
> -return __
> On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote:
>> This patch adds the old value param and the onchangeonly option
>> to the VM_EVENT_REASON_MOV_TO_MSR event.
>>
>> The param was added to the vm_event_mov_to_msr struct and to the
>> hvm_monitor_msr function. Finally I've changed
flight 116816 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
build-i386
On 21/11/17 12:06, Juergen Gross wrote:
> The "special pages" for PVH guests include the frames for console and
> Xenstore ring buffers. Those have to be marked as "Reserved" in the
> guest's E820 map, as otherwise conflicts might arise later e.g. when
> hotplugging memory into the guest.
>
> Sign
On 04/12/17 11:06, Jan Beulich wrote:
> p2m_pod_decrease_reservation() returning just (not) all-done is not
This would be easier to parse as "returning only all-done is not"
> sufficient for the caller: If some pages were processed,
> guest_remove_page() returning an error for those pages is the
On 04/12/17 11:06, Jan Beulich wrote:
> The function can be called for PV domains only, which commit 5a0b9fba92
> ("x86/mm: drop further relics of translated PV domains") sort of
> realized, but not fully.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
On 04/12/17 11:07, Jan Beulich wrote:
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mai
On 04/12/17 10:32, Jan Beulich wrote:
> Permissions that had been granted before should not be revoked when
> handling unrelated errors.
>
> Reported-by: HW42
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1918,6 +1918,7 @@ int map_domain_pirq(
> s
This run is configured for baseline tests only.
flight 72514 qemu-upstream-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72514/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhv
On 04/12/17 10:33, Jan Beulich wrote:
> ... instead of using redundant calculations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Now that pci_sbdf_t has been introduced, I should dust off my patch for %pP
~Andrew
___
Xen-devel mailing
Hi Stefano,
On Fri, Dec 01, 2017 at 02:58:57PM -0800, Stefano Stabellini wrote:
> On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
> > This is follow-up to our conversation during community call.
> > You asked me to send OP-TEE mediator as a patch, so we can
> > discuss it in the mailing list. So, th
Jan,
Do you have any further comments on the current version of this patch?.
Otherwise, I will work on the review comments and publish next version
of this patch later this week. Please let me know. Thanks.
Cheers
GOVINDA
On 12/1/2017 10:16 AM, Govinda Tatti wrote:
On 11/30/2017 8:46 AM, Ja
Hi Stefano
On Sat, Dec 2, 2017 at 3:21 AM, Stefano Stabellini
wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Dmytryshyn
>>
>> ACPI-specific parts are moved under appropriate ifdefs.
>> Now pmstat functions can be used in ARM platform.
>>
>> This is a rebased version
Hi Julien,
On Mon, Dec 04, 2017 at 02:30:32PM +, Julien Grall wrote:
> Hi,
>
> I am going to answer both e-mails (Stefano and Volodymyr) at once.
>
> On 01/12/17 22:58, Stefano Stabellini wrote:
> >On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
> >>This is follow-up to our conversation during
On 12/10/17 13:14, Jan Beulich wrote:
On 12.10.17 at 13:31, wrote:
>> On 12/10/17 11:01, Jan Beulich wrote:
>>> Don't accept anything other than r/w RAM pages and move the paged-out
>>> check into the (unlikely) error path following that check.
>>>
>>> Signed-off-by: Jan Beulich
>> How does
On 04/12/17 16:15, Volodymyr Babchuk wrote:
Hi Stefano,
On Fri, Dec 01, 2017 at 02:58:57PM -0800, Stefano Stabellini wrote:
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
This is follow-up to our conversation during community call.
You asked me to send OP-TEE mediator as a patch, so we can
di
On 12/10/17 13:24, Jan Beulich wrote:
> Silently assuming DOMID_SELF is unlikely to be a good idea for page
> table updates. For PGT_writable pages, though, it seems better to allow
> the writes, so the same check isn't being applied there.
>
> Also add blank lines between the individual case block
On 04/12/17 16:24, Volodymyr Babchuk wrote:
On Mon, Dec 04, 2017 at 02:30:32PM +, Julien Grall wrote:
On 01/12/17 22:58, Stefano Stabellini wrote:
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
= Page pinning =
Guest pages passed to OP-TEE need to be pinned (otherwise Xen doesn't
guarante
On 04/12/17 10:16, Jan Beulich wrote:
On 25.08.17 at 16:59, wrote:
> On 10.08.17 at 09:19, wrote:
>> On 10.07.17 at 12:39, wrote:
Real hardware wraps silently in most cases, so we should behave the
same. Also split real and VM86 mode handling, as the latter really
oug
>>> On 04.12.17 at 17:16, wrote:
> Do you have any further comments on the current version of this patch?.
No. I'm not fully understanding your most recent slot related comments,
but I'll trust you and Konrad to get this into suitable shape.
Jan
___
On Tue, Nov 21, 2017 at 12:06:06PM +0100, Juergen Gross wrote:
> The "special pages" for PVH guests include the frames for console and
> Xenstore ring buffers. Those have to be marked as "Reserved" in the
> guest's E820 map, as otherwise conflicts might arise later e.g. when
> hotplugging memory in
From: Boris Ostrovsky
Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them
NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses eflags
using 'pushfq' instruction when testing for IF bit. On PV Xen guests
looking at IF flag directly will always see it set, resulting in
>>> On 04.12.17 at 16:28, wrote:
> On 04/12/17 10:45, Jan Beulich wrote:
>> @@ -2477,10 +2478,9 @@ static int _put_page_type(struct page_in
>> continue;
>> /* We cleared the 'valid bit' so we do the clean up. */
>> rc = _put_final_page_type(pa
>>> On 04.12.17 at 17:07, wrote:
> On 04/12/17 10:32, Jan Beulich wrote:
>> Permissions that had been granted before should not be revoked when
>> handling unrelated errors.
>>
>> Reported-by: HW42
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -19
flight 72515 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail blocked in 72496
test-amd64-amd64-amd64-sid-n
>>> On 04.12.17 at 16:11, wrote:
> On 04/12/17 10:15, Jan Beulich wrote:
> On 03.07.17 at 16:56, wrote:
>> On 31.05.17 at 13:54, wrote:
>>> On 31.05.17 at 13:08, wrote:
> On 31/05/17 08:15, Jan Beulich wrote:
>> The flag is really only meant for those, both HVM and 32-bit PV
Hi,
On 04/12/17 09:00, Jan Beulich wrote:
On 01.12.17 at 16:31, wrote:
>> On 30/11/17 14:31, Jan Beulich wrote:
>>> Jann validly points out that with a caller bogusly requesting a zero-
>>> element batch with non-zero high command bits (the ones used for
>>> continuation encoding), the asser
Hi Julien,
On Mon, Dec 04, 2017 at 04:27:14PM +, Julien Grall wrote:
[...]
> >>= Error checking / DOS protection =
> >>
> >>We need powerful checks on arguments passed by the caller and evaluated
> >>by the mediator.
> >>
> >>For example, we cannot expect the guest to actually pass arguments
Hi, Stefano
On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Dmytryshyn
>>
>> First implementation of the cpufreq driver has been
>> written with x86 in mind. This patch makes possible
>> the cpufreq driver be working
The function migrate_fixed_message is going to be used in the libxl create and
save flow for event synchronization during migration. It needs to be accessible
from libxl_create and libxl_dom_save and thus it is moved to libxl_utils.
Signed-off-by: Bruno Alvisio
---
tools/libxl/libxl_utils.c | 21
For the migration with local disks mirroring scenario, the QEMU process is
started before the virtual RAM is transferred to the destination node so that
the QEMU embedded NBD server and disks mirroring jobs can be started. After the
virtual RAM and QEMU state are transferred, the QEMU process will
When the '-q' flag is provided to the 'xl migrate' command all the block devices
that are local should be mirrored to the destination node. If the flag is not
present migration flow will be equivalent to current migration flow. A new
'mirror_disks' field is added to the xl domain_create struct to i
Hi all,
I have worked on a solution to be able to migrate domains that use QEMU as the
backend disk driver. I have adapted the migration flow and piggybacked on the
"drive-mirroring" capability already provided by QEMU.
Overview
1. The "xl migrate" command has an additional "-q" flag. When provi
The libxl stream write receives stream phase type (DEFAULT, PRE_MIRROR_DISKS or
POST_MIRROR_DISKS) and registers the appropiate callback to the
libxl_save_helper. If the stream phase == PRE_MIRROR_DISKS the stream skips
writing the context record since it is written at a later time by the
POST_MIRR
Migration with Local Disk Mirroring uses the QEMU embedded NBD server. To
migrate the disk, a 'disk mirror job' is started from the source so that the
block devices emulated by QEMU are mirrored to the destination node. Once the
mirroring job is ready, QEMU sends an asynchronous QMP event. This cod
The domain save state contains a new 'mirror_disks' field. It determines the
flow of the domain save. If false, the save flow will invoke the DEFAULT phase
libxl/libxc stream type. If true, the save flow invokes the PRE_MIRROR_DISKS
phase stream type first. Upon reception of the signal from the sou
For migration with local disks mirroring a QEMU NBD server is started while
restoring the domain. This server will be responsible for receiving the disks
sent from the source node: The disks transfer will be triggered during the
domain save on the source using the QMP drive-mirror command.
A secon
The libxl streams are classified by a stream phase parameter (stream_phase):
0. DEFAULT: This is the stream phase when no local disks are being mirrored as
part of the domain save or restore flow. (=0)
1. POST_MIRROR_DISKS: This stream phase happens during the migration flow after
the disks have
Adapted libxc restore stream. Defined libxc stream phase types:
0. XC_STREAM_PHASE_DEFAULT: This is the stream phase when no local disks are
being mirrored as part of the domain save or restore (=0)
1. XC_STREAM_PHASE_POST_MIRROR_DISKS: This stream phase transfers the virtual
RAM from source to d
A new op pre_mirror_stream_phase is introduced as part of the xc_sr_save_ops.
This op sends all pfns and params that need to be transferred before the disks
mirroring jobs can be started. Note that no new libxc record type is created.
The save flow is modified such that: if the stream_phase ==
XC_
A new field 'mirror_disks' is added to the libxl struct
libxl__domain_create_state to record if QEMU drives should be mirrored during
migration. This variable is used to setup the sequence of calls and streams in
libxl and libxc.
Signed-off-by: Bruno Alvisio
---
tools/libxl/libxl.h
Migration with local disks mirroring uses the embedded NBD server in QEMU. A NBD
server is added in libxl during instance creation time in the destination (QMP
command: nbd_server_add). The drive mirror command (QMP: driver_mirror) is
executed on the source during 'instance save' to replicate the d
flight 116810 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
115643
test-amd64-am
1 - 100 of 125 matches
Mail list logo
