flight 158414 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158414/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da45a3608787d77fc55d915bee3903f5119b3ee6
baseline version:
ovmf ebfe2d3eb5ac7fd92d740
On Wed, 13 Jan 2021, Jakub Kicinski wrote:
> On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> > Resending the stragglers again.
> >
> >
> > This set is part of a larger effort attempting to clean-up W=1
On 13.01.2021 00:30, Stefano Stabellini wrote:
> On Tue, 12 Jan 2021, Jan Beulich wrote:
>> On 08.01.2021 15:46, Rahul Singh wrote:
>>> -Wimplicit-fallthrough warns when a switch case falls through. Warning
>>> can be suppress by either adding a /* fallthrough */ comment, or by
>>> using a null sta
flight 158410 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
On Wed, Jan 13, 2021 at 8:42 PM Christoph Hellwig wrote:
>
> > +#ifdef CONFIG_SWIOTLB
> > + struct io_tlb_mem *dma_io_tlb_mem;
> > #endif
>
> Please add a new config option for this code instead of always building
> it when swiotlb is enabled.
>
> > +static int swiotlb_init_io_tlb_mem(s
On 13.01.2021 20:05, Julien Grall wrote:
> On 28/11/2020 11:36, Julien Grall wrote:
>> From: Julien Grall
>>
>> init_one_desc_irq() can return an error if it is unable to allocate
>> memory. While this is unlikely to happen during boot (called from
>> init_{,local_}irq_data()), it is better to har
On Wed, Jan 13, 2021 at 7:48 AM Florian Fainelli wrote:
>
> On 1/5/21 7:41 PM, Claire Chang wrote:
> > If a device is not behind an IOMMU, we look up the device node and set
> > up the restricted DMA when the restricted-dma-pool is presented.
> >
> > Signed-off-by: Claire Chang
> > ---
>
> [snip]
On 14/01/2021 09:15, Jan Beulich wrote:
On 13.01.2021 20:05, Julien Grall wrote:
On 28/11/2020 11:36, Julien Grall wrote:
From: Julien Grall
init_one_desc_irq() can return an error if it is unable to allocate
memory. While this is unlikely to happen during boot (called from
init_{,local_}i
On 13.01.2021 20:09, Julien Grall wrote:
> On 04/12/2020 10:43, Jan Beulich wrote:
>> Adjust so we uniformly avoid needlessly arranging for a continuation on
>> the last iteration.
>>
>> Fixes: 5777a3742d88 ("IOMMU: hold page ref until after deferred TLB flush")
>
> I view this patch as an optimiz
On 14.01.2021 00:16, Andrew Cooper wrote:
> On 05/01/2021 15:56, Jan Beulich wrote:
>> On 23.12.2020 17:34, Andrew Cooper wrote:
>>> RFC:
>>> * This probably wants to be less fatal in release builds
>> I'm not even convinced this wants to be a panic() in debug builds.
>
> Any memory leak spotted
On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
> On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
> >
> > On Wed, Jan 13, 2021 at 1:06 PM Roger Pau Monné
> > wrote:
> > >
> > > On Wed, Jan 13, 2021 at 10:48:52AM -0500, Jason Andryuk wrote:
>
>
>
> > > > I have some laptops
On Wed, Jan 13, 2021 at 09:00:47PM +, Andrew Cooper wrote:
> On 12/01/2021 15:51, Roger Pau Monné wrote:
> > On Tue, Jan 12, 2021 at 09:48:17AM -0500, Jason Andryuk wrote:
> >> On Tue, Jan 12, 2021 at 9:25 AM Roger Pau Monné
> >> wrote:
> >>> Dropping Qing He as this address bounces.
> >>>
>
On 12.01.2021 19:12, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> Use unsigned char variable, or cast to (unsigned char), for
> tolower()/islower() and friends. Fix compiler error
> array subscript has type 'char' [-Werror=char-subscripts]
Isn't this something that wants changing in your ctype
On 13.01.2021 22:31, Jason Andryuk wrote:
> On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
>> I guess I'd also need to disable MSI for the two devices to ensure
>> they are both using the GSI?
>
> lspci in dom0 shows the USB xhci controller, iwlwifi, and e1000e
> devices all with IRQ 16 and
On 14.01.2021 11:22, Roger Pau Monné wrote:
> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
>> On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
>>> I guess I'd also need to disable MSI for the two devices to ensure
>>> they are both using the GSI?
>>
>> lspci in dom0 shows the
On 13.01.2021 14:11, Roger Pau Monné wrote:
> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
>>> From: Roger Pau Monne
>>> As with previous patches, I'm having a hard time figuring out why this
>>> was required in the first place. I see no reason for Xen to be
>>> deasserting the gue
On 12.01.2021 18:32, Roger Pau Monne wrote:
> @@ -967,10 +879,10 @@ static void hvm_pirq_eoi(struct pirq *pirq)
> * since interrupt is still not EOIed
> */
> if ( --pirq_dpci->pending ||
> - !pt_irq_need_timer(pirq_dpci->flags) )
> + /* When the interrupt source is
On 14/01/2021 11:48, Jan Beulich wrote:
> On 13.01.2021 14:11, Roger Pau Monné wrote:
>> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
From: Roger Pau Monne
As with previous patches, I'm having a hard time figuring out why this
was required in the first place. I see n
On 14.01.2021 12:56, Andrew Cooper wrote:
> On 14/01/2021 11:48, Jan Beulich wrote:
>> On 13.01.2021 14:11, Roger Pau Monné wrote:
>>> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> From: Roger Pau Monne
> As with previous patches, I'm having a hard time figuring out why th
On Thu, Jan 14, 2021 at 11:53:20AM +0100, Jan Beulich wrote:
> On 12.01.2021 19:12, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Use unsigned char variable, or cast to (unsigned char), for
> > tolower()/islower() and friends. Fix compiler error
> > array subscript has type 'char' [-Werror
On Thu, Jan 14, 2021 at 12:45:27PM +0100, Jan Beulich wrote:
> On 14.01.2021 11:22, Roger Pau Monné wrote:
> > On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
> >> On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
> >>> I guess I'd also need to disable MSI for the two devices to
On Thu, Jan 14, 2021 at 12:48:59PM +0100, Jan Beulich wrote:
> On 13.01.2021 14:11, Roger Pau Monné wrote:
> > On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> >>> From: Roger Pau Monne
> >>> As with previous patches, I'm having a hard time figuring out why this
> >>> was required in
On Thu, Jan 14, 2021 at 01:12:00PM +0100, Jan Beulich wrote:
> On 14.01.2021 12:56, Andrew Cooper wrote:
> > On 14/01/2021 11:48, Jan Beulich wrote:
> >> On 13.01.2021 14:11, Roger Pau Monné wrote:
> >>> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> >
flight 158417 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158417/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 536a3e67263b6d891152c0511cbdbbadf42a7360
baseline version:
ovmf da45a3608787d77fc55d9
On 14.01.2021 13:29, Manuel Bouyer wrote:
> On Thu, Jan 14, 2021 at 11:53:20AM +0100, Jan Beulich wrote:
>> On 12.01.2021 19:12, Manuel Bouyer wrote:
>>> From: Manuel Bouyer
>>>
>>> Use unsigned char variable, or cast to (unsigned char), for
>>> tolower()/islower() and friends. Fix compiler error
On 14.01.2021 13:54, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 12:48:59PM +0100, Jan Beulich wrote:
>> On 13.01.2021 14:11, Roger Pau Monné wrote:
>>> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> From: Roger Pau Monne
> As with previous patches, I'm having a hard t
On 14.01.2021 13:58, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 01:12:00PM +0100, Jan Beulich wrote:
>> On 14.01.2021 12:56, Andrew Cooper wrote:
>>> On 14/01/2021 11:48, Jan Beulich wrote:
On 13.01.2021 14:11, Roger Pau Monné wrote:
> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian,
On 14.01.2021 13:33, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 12:45:27PM +0100, Jan Beulich wrote:
>> On 14.01.2021 11:22, Roger Pau Monné wrote:
>>> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
> I guess I'd a
flight 158413 qemu-mainline real [real]
flight 158419 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158413/
http://logs.test-lab.xenproject.org/osstest/logs/158419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
The max_message_size field of the output gets filled only when the flags
field is non-zero. Don't copy back uninitialized data to guest context.
Signed-off-by: Jan Beulich
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1405,7 +1405,8 @@ fill_ring_data(const struct domain *curr
rcu_
It's not overly difficult for a domain to figure out its ID, so
requiring the use of DOMID_SELF in a very limited set of places isn't
really helpful towards keeping the ID opaque to the guest.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2776,15 +2
On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
> On 14.01.2021 13:29, Manuel Bouyer wrote:
> > On Thu, Jan 14, 2021 at 11:53:20AM +0100, Jan Beulich wrote:
> >> On 12.01.2021 19:12, Manuel Bouyer wrote:
> >>> From: Manuel Bouyer
> >>>
> >>> Use unsigned char variable, or cast to (uns
Hi Jan,
On 14/01/2021 14:02, Jan Beulich wrote:
It's not overly difficult for a domain to figure out its ID, so
requiring the use of DOMID_SELF in a very limited set of places isn't
really helpful towards keeping the ID opaque to the guest.
So I agree that a domid can be figured out really eas
On 14/01/2021 14:02, Jan Beulich wrote:
> It's not overly difficult for a domain to figure out its ID, so
> requiring the use of DOMID_SELF in a very limited set of places isn't
> really helpful towards keeping the ID opaque to the guest.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/grant_t
... shadow adjustments towards not building 2- and 3-level code
when !HVM. While the latter isn't functionally related to the
former, it depends on some of the rearrangements done there.
01: shadow: use __put_user() instead of __copy_to_user()
02: split __{get,put}_user() into "guest" and "unsafe"
In a subsequent patch I would almost have broken the logic here, if I
hadn't happened to read through the comment at the top of
safe_write_entry(): __copy_from_user() does not provide a guarantee
shadow_write_entries() requires - it's only an optimization that it
makes use of __put_user_size() for
The "guest" variants are intended to work with (potentially) fully guest
controlled addresses, while the "unsafe" variants are not. (For
descriptor table accesses the low bits of the addresses may still be
guest controlled, but this still won't allow speculation to "escape"
into unwanted areas.) Su
The "guest" variants are intended to work with (potentially) fully guest
controlled addresses, while the "unsafe" variants are not. Subsequently
we will want them to have different behavior, so as first step identify
which one is which. For now, both groups of constructs alias one another.
Double
Inspired by
https://lore.kernel.org/lkml/f12e7d3cecf41b2c29734ea45a393be21d4a8058.1597848273.git.jpoim...@redhat.com/
and prior work in that area of x86 Linux, suppress speculation with
guest specified pointer values by suitably masking the addresses to
non-canonical space in case they fall into Xe
Bring them (back) in line with __{get,put}_guest().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1626,19 +1626,19 @@ static void load_segments(struct vcpu *n
if ( !ring_1(regs) )
{
-ret = put_user(regs->ss,
Using copy_{from,to}_user(), this code was assuming to be called only by
PV guests. Use copy_{from,to}_guest() instead, transforming the incoming
structure field into a guest handle (the field should really have been
one in the first place). Also do not transform the debuggee address into
a pointer
Bring them (back) in line with __copy_{from,to}_guest_pv(). Since it
falls in the same group, also convert clear_user(). Instead of adjusting
__raw_clear_guest(), drop it - it's unused and would require a non-
checking __clear_guest_pv() which we don't have.
Add previously missing __user at some c
... to {get,put}_unsafe_size(). There's no need to have the macros
expanded once per case label in the latter. This also makes the former
well-formed single statements again. No change in generated code.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uac
The former expands to a single (memory accessing) insn, which the latter
does not guarantee. Yet we'd prefer to read consistent PTEs rather than
risking a split read racing with an update done elsewhere.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/mm.c
+++ b/xen/arch/x86/pv/mm.c
@@ -41,9 +4
This is the slightly more direct way of getting at what we want, and
better in line with shadow_write_entries()'s use of put_unsafe().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2614,10 +2614,9 @@ static int sh_page_fault(struct vcpu
First of all, avoid the initial dummy write: Try to write the actual
new value instead, and start the loop from 1 if this was successful.
Further, drop safe_write_entry() and use write_atomic() instead. This
eliminates the need for the BUILD_BUG_ON() there at the same time.
Then
- use const and un
The few GUEST_PAGING_LEVELS dependencies (of shadow_set_l2e() only) can
be easily expressed by function parameters; I suppose the extra indirect
call is acceptable for the increasingly little used 32-bit non-PAE case.
This way shadow_set_l[12]e(), each of which compiles to almost 1k of
code, need b
Use SHF_L1_ANY, SHF_32, SHF_PAE, as well as SHF_64, and introduce
SHF_FL1_ANY.
Note that in shadow_audit_tables() this has the effect of no longer
(I assume mistakenly, or else I don't see why the respective callback
table entry isn't NULL) excluding SHF_L2H_64.
Signed-off-by: Jan Beulich
--- a
..., i.e. being used only with 4 guest paging levels. Drop its L2/PAE
alias and adjust / drop conditionals. Use >= 4 where touching them
anyway, in preparation for 5-level paging.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -334,7 +334,
This is a remnant from 32-bit days, having no place anymore where a
shadow of this type would be created.
Signed-off-by: Jan Beulich
---
hash_{domain,vcpu}_foreach() have a use each of literal 15. It's not
clear to me what the proper replacement constant would be, as it
doesn't look as if SH_type
In order to limit #ifdef-ary, provide "stub" #define-s for
SH_type_{l1,fl1,l2}_{32,pae}_shadow and SHF_{L1,FL1,L2}_{32,PAE}.
The change in shadow_vcpu_init() is necessary to cover for "x86: correct
is_pv_domain() when !CONFIG_PV" (or any other change along those lines)
- we should only rely on is_
To cover for "x86: correct is_pv_domain() when !CONFIG_PV" (or any other
change along those lines) we should prefer is_hvm_*(), as it may become
a build time constant while is_pv_*() generally won't.
Also when a domain pointer is in scope, prefer is_*_domain() over
is_*_vcpu().
Signed-off-by: Jan
Getting rid of the literal number has been something I've been
hoping to see happen for perhaps over 10 years, along with
doing away with some unnecessary refusal of operations. The
other two changes are "collateral damage" from doing that
change.
1: gnttab: adjust pin count overflow checks
2: gnt
It's at least odd to check counters which aren't going to be
incremented. And it's also not helpful to use open-coded literal numbers
in these checks.
Calculate the increment values first and derive from them the mask to
use in the checks.
Also move the pin count checks ahead of the calculation o
Forever since the fix for XSA-230 the 2nd of the comments ahead of
fixup_status_for_copy_pin() has been stale - there's nothing specific to
transitive grants there anymore.
Move the function up, drop the "copy" part from its name again, add a
"readonly" parameter, and use it also on other paths ha
On 14.01.21 05:55, Wei Chen wrote:
Hi Oleksandr,
Hi Wei.
I have tested this series with latest master and staging branches.
The virtio function works well for Arm as v3.
Thank you! This is good news.
For latest staging branch, it needs a tiny rebase for:
0011 xen/mm: Make x86's XENM
I can only assume that f2ae59bc4b9b ("Rationalize max_grant_frames and
max_maptrack_frames handling") unintentionally left Arm's create_domUs()
set limits to explicit values, as at least some of the same constraints
apply here.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/domain_build.c
+++ b/x
On 14/01/2021 10:14, Jan Beulich wrote:
> On 14.01.2021 00:16, Andrew Cooper wrote:
>> On 05/01/2021 15:56, Jan Beulich wrote:
>>> On 23.12.2020 17:34, Andrew Cooper wrote:
RFC:
* This probably wants to be less fatal in release builds
>>> I'm not even convinced this wants to be a panic()
On 14.01.2021 15:43, Julien Grall wrote:
> On 14/01/2021 14:02, Jan Beulich wrote:
>> It's not overly difficult for a domain to figure out its ID, so
>> requiring the use of DOMID_SELF in a very limited set of places isn't
>> really helpful towards keeping the ID opaque to the guest.
>
> So I agre
On 14.01.21 05:58, Wei Chen wrote:
Hi Oleksandr,
Hi Wei
-Original Message-
From: Xen-devel On Behalf Of
Oleksandr Tyshchenko
Sent: 2021年1月13日 5:52
To: xen-devel@lists.xenproject.org
Cc: Julien Grall ; Jan Beulich ;
Andrew Cooper ; Roger Pau Monné
; Wei Liu ; George Dunlap
; Ian
On 14/01/2021 15:30, Jan Beulich wrote:
> On 14.01.2021 15:43, Julien Grall wrote:
>> On 14/01/2021 14:02, Jan Beulich wrote:
>>> It's not overly difficult for a domain to figure out its ID, so
>>> requiring the use of DOMID_SELF in a very limited set of places isn't
>>> really helpful towards keep
Rename the xenevtchn_open() parameter open_flags to flags as it might
be used for things not passed on to open().
No functional change.
Suggested-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
V11:
- new patch (Andrew Cooper)
---
tools/include/xenevtchn.h | 2 +-
tools/libs/evtchn/core.c
Today Xenstore is not restartable. This means a Xen server needing an
update of xenstored has to be rebooted in order to let this update
become effective.
This patch series is changing that: The internal state of xenstored
(the contents of Xenstore, all connections to various clients like
programs
Propagate the flags parameter of xenevtchn_open() to the OS-specific
handlers in order to enable handling them there.
Signed-off-by: Juergen Gross
---
V11:
- new patch (carved out from patch 4 of V10, Andrew Cooper)
---
tools/libs/evtchn/core.c| 2 +-
tools/libs/evtchn/freebsd.c | 2 +-
tool
Refuse a call of xenevtchn_open() with unsupported bits in flags being
set.
Suggested-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
V11:
- new patch (Andrew Cooper)
---
tools/libs/evtchn/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/libs/evtchn/
In order to allow control commands with binary data refactor handling
of XS_CONTROL:
- get primary command first
- add maximum number of additional parameters to pass to command
handler
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Reviewed-by: Paul Durrant
---
V2:
- add comment reg
Today the file descriptor for the access of the event channel driver
is being closed in case of exec(2). For the support of live update of
a daemon using libxenevtchn this can be problematic, so add a way to
keep that file descriptor open.
Add support of a flag XENEVTCHN_NO_CLOEXEC for xenevtchn_o
Add the "live-update" command to xenstore-control enabling updating
xenstored to a new version in a running Xen system.
With -c it is possible to pass a different command line to the
new instance of xenstored. This will replace the command line used
for the invocation of the just running xenstore
There is a mixture of different styles in libxenevtchn. Use the
standard xen style only.
No functional change.
Signed-off-by: Juergen Gross
---
V11:
- new patch
---
tools/libs/evtchn/core.c| 24 +
tools/libs/evtchn/freebsd.c | 25 +++---
tools/libs/evtchn/linux.c | 4 ++
tool
Updating an instance of Xenstore via live update needs to hand over
the command line parameters to the updated instance. Those can be
either the parameters used by the updated instance or new ones when
supplied when starting the live update.
So when supplied store the new command line parameters i
Add an include file containing all structures and defines needed for
dumping and restoring the internal Xenstore state.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
---
V4:
- drop mfn from connection record (rebase to V5 of state doc patch)
- add #ifdef __MINIOS__ (Julien Grall)
- correct
Save the new binary name for the daemon case and the new kernel for
stubdom in order to support live update of Xenstore..
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_control.c | 41 +-
1 file changed,
Live update of Xenstore is done in multiple steps. It needs a status
block holding the current state of live update and related data. It
is allocated as child of the connection live update was started over
in order to abort live update in case the connection is closed.
Allocation of the block is d
Add the basic parts for parsing the live-update control command.
For now only add the parameter evaluation and calling appropriate
functions. Those function only print a message for now and return
success.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Julien Grall
---
V2:
Today a Xenstore request is processed as soon as it is seen by
xenstored. Add the framework for being able to delay processing of a
request if the right conditions aren't met.
Any delayed requests are executed at the end of the main processing
loop in xenstored. They can either delay themselves ag
From: Julien Grall
A domain could just be dying when live updating Xenstore, so the case
of not being able to map the ring page or to connect to the event
channel must be handled gracefully.
Signed-off-by: Julien Grall
Reviewed-by: Paul Durrant
---
V4:
- new patch (Julien, I hope adding the So
In order to simplify live update state dumping only allow live update
to happen when no transaction is active.
A timeout is used to detect guests which have a transaction active for
longer periods of time. In case such a guest is detected when trying
to do a live update it will be reported and the
For live update the functionality to introduce a new domain similar to
the XS_INTRODUCE command is needed, so split that functionality off
into a dedicated function introduce_domain().
Switch initial dom0 initialization to use this function, too.
Signed-off-by: Juergen Gross
Reviewed-by: Julien
Add reading the global state for live update.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Reviewed-by: Paul Durrant
---
tools/xenstore/xenstored_control.c | 1 +
tools/xenstore/xenstored_core.c| 9 +
tools/xenstore/xenstored_core.h| 2 ++
3 files changed, 12 insertions(
Add the main framework for executing the live update. This for now
only defines the basic execution steps with empty dummy functions.
This final step returning means failure, as in case of success the
new executable will have taken over.
Signed-off-by: Juergen Gross
---
V4:
- const (Julien Grall)
Add the needed functions for reading node state for live update.
This requires some refactoring of current node handling in Xenstore in
order to avoid repeating the same code patterns multiple times.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Julien Grall
---
V4:
- drop l
On 14.01.2021 16:01, Andrew Cooper wrote:
> On 14/01/2021 14:02, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2776,15 +2776,19 @@ struct gnttab_copy_buf {
>> static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
>>
Add activation of the new binary for live update. The daemon case is
handled completely, while for stubdom we only add stubs.
Signed-off-by: Juergen Gross
---
V7:
- added unbinding dom0 and virq event channels
V8:
- no longer close dom0 evtchn (Julien Grall)
V10:
- remember original argc and ar
When started due to a live upgrade read the internal state and apply
it to the data base and internal structures.
Add the main control functions for that.
For now only handle the daemon case.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Julien Grall
---
V4:
- directly mmap
For support of live update the locally used files need to have the
"close on exec" flag set. Fortunately the used Xen libraries are
already doing this, so only the logging and tdb related files and
pipes are affected. openlog() has the close on exec attribute, too.
In order to be able to keep the
Dump the complete Xenstore status to a file (daemon case) or memory
(stubdom case).
As we don't know the exact length of the needed area in advance we are
using an anonymous rather large mapping in stubdom case, which will
use only virtual address space until accessed. And as we are writing
the ar
In the live update case several initialization steps of xenstore must
be omitted or modified. Add the proper handling for that.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V4:
- set xprintf = trace in daemon case (Julien Grall)
- only update /tool/xenstored node contents
V7:
- so
For live update of Xenstore some records defined in the migration
stream document need to be changed:
- Support of the read-only socket has been dropped from all Xenstore
implementations, so ro-socket-fd in the global record can be removed.
- Some guests require the event channel to Xenstore to
Add the needed functions for reading connection state for live update.
As the connection is identified by a unique connection id in the state
records we need to add this to struct connection. Add a new function
to return the connection based on a connection id.
Signed-off-by: Juergen Gross
Revie
Add reading the watch state records for live update.
This requires factoring out some of the add watch functionality into a
dedicated function.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V4:
- add comment (Julien Grall)
V6:
- correct check_watch_path() (setting errno)
---
tool
flight 158420 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158420/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The last posting date for new feature patches for Xen 4.15 is
tomorrow. [1] We seem to be getting a reasonable good flood of stuff
trying to meet this deadline :-).
Patches for new fetures posted after tomorrow will be deferred to the
next Xen release after 4.15. NB the primary responsibility fo
Hi, thanks for giving this update.
Since you were the only person who took the time to send such an
update I feel I can spend some time on trying to help with any
obstacles you may face. Hence this enquiry:
Oleksandr writes ("Re: [ANNOUNCE] Xen 4.15 release schedule and feature
tracking"):
> I
flight 158416 xen-unstable real [real]
flight 158423 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158416/
http://logs.test-lab.xenproject.org/osstest/logs/158423/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
On 14.01.21 16:37, Juergen Gross wrote:
Today Xenstore is not restartable. This means a Xen server needing an
update of xenstored has to be rebooted in order to let this update
become effective.
This patch series is changing that: The internal state of xenstored
(the contents of Xenstore, all co
On Thu, Jan 14, 2021 at 03:01:06PM +0100, Jan Beulich wrote:
> The max_message_size field of the output gets filled only when the flags
> field is non-zero. Don't copy back uninitialized data to guest context.
I'm afraid I'm missing something. AFAICT ent gets filled from the
user-space contents of
On 14.01.2021 17:59, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 03:01:06PM +0100, Jan Beulich wrote:
>> The max_message_size field of the output gets filled only when the flags
>> field is non-zero. Don't copy back uninitialized data to guest context.
>
> I'm afraid I'm missing something. AF
On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
> On Wed, 13 Jan 2021, Jakub Kicinski wrote:
>
> > On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> > > Resending the stragglers again.
> > >
> > >
> > > T
On Thu, Jan 14, 2021 at 02:41:29PM +0100, Jan Beulich wrote:
> On 14.01.2021 13:33, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 12:45:27PM +0100, Jan Beulich wrote:
> >> On 14.01.2021 11:22, Roger Pau Monné wrote:
> >>> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
> On
Oleksandr Tyshchenko writes ("[PATCH V4 24/24] [RFC] libxl: Add support for
virtio-disk configuration"):
> This patch adds basic support for configuring and assisting virtio-disk
> backend (emualator) which is intended to run out of Qemu and could be run
> in any domain.
Thanks. I think this is
1 - 100 of 139 matches
Mail list logo
