>>> On 08.11.18 at 23:27, wrote:
> On Thu, 8 Nov 2018, Jan Beulich wrote:
>> >>> On 06.11.18 at 23:05, wrote:
>> > ---
>> > xen/arch/arm/alternative.c | 7 ++--
>> > xen/arch/arm/arm32/livepatch.c | 2 +-
>> > xen/arch/arm/arm64/livepatch.c | 2 +-
>> >
Ping?
Jan's remark regarding de-privileged qemu is no issue as the hypercall
node is being closed by the de-privilege library function.
Juergen
On 01/11/2018 13:33, Juergen Gross wrote:
> Currently the size of hypercall buffers allocated via
> /dev/xen/hypercall is limited to a default of 64
On 09/11/2018 07:53, Jacob Wen wrote:
> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY is already able to make sure backend sees
> requests before req_prod is updated.
>
> Signed-off-by: Jacob Wen
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY is already able to make sure backend sees
requests before req_prod is updated.
Signed-off-by: Jacob Wen
---
drivers/net/xen-netfront.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index
flight 129686 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129540 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129540/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 128837
test-armhf-armhf-xl-rtds 16
On 09/11/2018 02:10, Manjunath Patil wrote:
> When we try to detach the device, blkfront_remove() tries to access
> blkfront_info leading to kernel panic.
>
> Typical call stack involving panic -
> #10 page_fault at 816f25df
> [exception RIP: blkif_free+46]
> #11 blkfront_remove at
flight 129682 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
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
flight 129678 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129678/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129530 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
flight 129662 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
flight 129532 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129532/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw broken
When we try to detach the device, blkfront_remove() tries to access
blkfront_info leading to kernel panic.
Typical call stack involving panic -
#10 page_fault at 816f25df
[exception RIP: blkif_free+46]
#11 blkfront_remove at a004de47 [xen_blkfront]
#12 xenbus_dev_remove at
If a hot-attaching device fails inside domU[ex:negotiate_mq() returns
with ENOMEM] we clear the blkfront_info struct in talk_to_blkback()
When we try to detach the device, blkfront_remove() tries to access
blkfront_info leading to kernel panic.
Typical call stack involving panic -
#10
This run is configured for baseline tests only.
flight 75582 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 11 guest-start
On Thu, 8 Nov 2018, Jan Beulich wrote:
> >>> On 06.11.18 at 23:05, wrote:
> > Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it
> > is required when comparing and subtracting pointers [1], but use it
> > everywhere to avoid confusion.
>
> I think using it when not needed is
On Thu, 8 Nov 2018, Jan Beulich wrote:
> >>> On 06.11.18 at 23:05, wrote:
> > --- a/xen/include/xen/compiler.h
> > +++ b/xen/include/xen/compiler.h
> > @@ -99,6 +99,12 @@
> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> > (typeof(ptr)) (__ptr + (off)); })
> >
> > +/*
> > + * Use
flight 129656 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129656/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Nov 08, 2018 at 08:46:12PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 8:27 PM, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
> >> On 11/8/18 8:02 PM, Wei Liu wrote:
> >>> Speaking of build breakage: would you guys consider signing up to gitlab
> >>> so
> From: Xin Li
>
> Filling dummy module's hook to null value of xsm_operations structure
> will generate debug message. This becomes boot time spew for module
> like silo, which only sets a few hooks of itself. So remove the printing
> to avoid boot time spew.
>
> Signed-off-by: Xin Li
flight 129604 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
Hi,
On 11/7/18 7:01 PM, Stefano Stabellini wrote:
On Wed, 7 Nov 2018, Julien Grall wrote:
On 07/11/2018 12:18, Julien Grall wrote:
Hi Stefano,
On 07/11/2018 00:32, Stefano Stabellini wrote:
On Mon, 22 Oct 2018, Julien Grall wrote:
Hi,
On 09/10/2018 00:37, Stefano Stabellini wrote:
On 08/11/2018 16:45, Daniel Kiper wrote:
> On Fri, Nov 02, 2018 at 01:37:27PM +0100, Juergen Gross wrote:
>> Add the hooks to current code needed for Xen PVH. They will be filled
>> with code later when the related functionality is being added.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> V3:
On 11/8/18 8:27 PM, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
>> On 11/8/18 8:02 PM, Wei Liu wrote:
>>> Speaking of build breakage: would you guys consider signing up to gitlab
>>> so that you can use all the build test infrastructure there before
>>>
On 11/8/18 8:14 PM, George Dunlap wrote:
> On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The reason is the way
>> Xen
On 08/11/18 18:30, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 06:29:05PM +, Andrew Cooper wrote:
>> On 08/11/18 18:08, Wei Liu wrote:
>>> 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
>>> truth table for what `xl info` would report. In order to make the
>>> table work xen
On Thu, Nov 08, 2018 at 06:29:05PM +, Andrew Cooper wrote:
> On 08/11/18 18:08, Wei Liu wrote:
> > 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
> > truth table for what `xl info` would report. In order to make the
> > table work xen will need to report its PV capability.
>
On 08/11/18 18:08, Wei Liu wrote:
> 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
> truth table for what `xl info` would report. In order to make the
> table work xen will need to report its PV capability.
>
> Replace cap_directio with cap_pv in libxl IDL. It is safe to do so
>
On Thu, Nov 08, 2018 at 12:27:40PM -0600, Doug Goldstein wrote:
>
> > On Nov 8, 2018, at 12:09 PM, Wei Liu wrote:
> >
> >> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> >> Signed-off-by: Wei Liu
> >
> > I will commit these two patches without acks. They are a net benefit to
> >
On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 8:02 PM, Wei Liu wrote:
> > Speaking of build breakage: would you guys consider signing up to gitlab
> > so that you can use all the build test infrastructure there before
> > submission? It would probably say you from
> On Nov 8, 2018, at 12:09 PM, Wei Liu wrote:
>
>> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
>> Signed-off-by: Wei Liu
>
> I will commit these two patches without acks. They are a net benefit to
> Xen -- I don't think that will be controversial.
>
> Wei.
Sounds good to me.
On 11/8/18 8:02 PM, Wei Liu wrote:
> Speaking of build breakage: would you guys consider signing up to gitlab
> so that you can use all the build test infrastructure there before
> submission? It would probably say you from building local for different
> distros and configs.
>
> See
On 08/11/18 18:09, Wei Liu wrote:
> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
>> Signed-off-by: Wei Liu
> I will commit these two patches without acks. They are a net benefit to
> Xen -- I don't think that will be controversial.
LGTM. Acked-by: Andrew Cooper
On Thu, Nov 08, 2018 at 06:13:23PM +, Andrew Cooper wrote:
> On 08/11/18 18:09, Wei Liu wrote:
> > On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> >> Signed-off-by: Wei Liu
> > I will commit these two patches without acks. They are a net benefit to
> > Xen -- I don't think that
On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty VGA: it
On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
I will commit these two patches without acks. They are a net benefit to
Xen -- I don't think that will be controversial.
Wei.
___
Xen-devel mailing list
0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
truth table for what `xl info` would report. In order to make the
table work xen will need to report its PV capability.
Replace cap_directio with cap_pv in libxl IDL. It is safe to do so
because cap_directio has never been
On Thu, Nov 08, 2018 at 07:56:29PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 7:22 PM, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 05:56:07PM +0200, Razvan Cojocaru wrote:
> >> On 11/8/18 5:53 PM, Wei Liu wrote:
> >>> On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
> On
flight 129650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129650/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Nov 08, 2018 at 05:46:51PM +, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 11/8/18 7:22 PM, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 05:56:07PM +0200, Razvan Cojocaru wrote:
>> On 11/8/18 5:53 PM, Wei Liu wrote:
>>> On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> On Mon, Nov 5, 2018 at 2:54 AM
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/pv/dom0_build.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 21d262b..812b026 100644
---
On 08/11/18 17:31, Andrew Cooper wrote:
> On 08/11/18 17:28, Ian Jackson wrote:
>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 01/11] tools/libs/toollog:
>> Provide a default logger"):
>>> You want something like:
>>>
>>> static xentoollog_logger_stdiostream stdio_logger = {
>>> .vtable
On 08/11/18 17:28, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 01/11] tools/libs/toollog:
> Provide a default logger"):
>> You want something like:
>>
>> static xentoollog_logger_stdiostream stdio_logger = {
>> .vtable = {
>> .vmessage = stdiostream_vmessage,
On 08/11/18 17:07, Ian Jackson wrote:
> This is most conveniently done like this because xtl_logger_stdio.c
> knows how to provide a static logger without doing any memory
> allocations. That's useful because it can't fail.
>
> Add the new symbol to the map file and bump the minor version
>
Hello Ian,
On Tue, Oct 09, 2018 at 03:04:52AM -0600, Jan Beulich wrote:
> >>> On 09.10.18 at 10:38, wrote:
> > On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> >> All,
> >>
> >> both releases are due in about a month's time. Please point out
> >> backports you find missing from
Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 01/11] tools/libs/toollog:
Provide a default logger"):
> You want something like:
>
> static xentoollog_logger_stdiostream stdio_logger = {
> .vtable = {
> .vmessage = stdiostream_vmessage,
> .progress = stdiostream_progress,
>
On Thu, Nov 08, 2018 at 05:56:07PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 5:53 PM, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
> >> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> >>> On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
> >>> wrote:
>
On Thu, Nov 08, 2018 at 09:25:26AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 14:20, wrote:
> > On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 13:47, wrote:
> >> > My point would be that on x86 I think the only way to have preemptible
> >> > long-running
* Use xs_close instead of the deprecated xs_daemon_close.
* Initialise xs to NULL.That means xs_close can now be called in
all cases. Move it to the fail clause.
* free(domid_str) is already safe in all cases since domid_str is
initialised to NULL. Move it to the fail clause.
No
* Promise that we will set errno to ENOENT if the server is not
yet set up.
* Arrange that all ENOENT returns other than from the read of ring-ref
are turned into EIO, logging when we do so.
Signed-off-by: Ian Jackson
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c| 11
This is most conveniently done like this because xtl_logger_stdio.c
knows how to provide a static logger without doing any memory
allocations. That's useful because it can't fail.
Add the new symbol to the map file and bump the minor version
accordingly.
Signed-off-by: Ian Jackson
CC: Wei Liu
And place it into .text.cold.
Requested-by: Jan Beulich
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 20 +---
xen/include/xen/init.h | 1 +
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/x86_64/traps.c
Previously xtl_log, xtl_logv and xtl_progress would all crash if
passed logger=NULL. Have the use the default logger instead.
This is more convenient.
Signed-off-by: Ian Jackson
CC: Wei Liu
---
v2: New in this version of the series
---
tools/libs/toollog/include/xentoollog.h | 9 +
* Abolish fail_xs_open which is now exactly the same as fail.
* Change all gotos to refer to fail instead.
No functional change.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c | 13 ++---
1 file changed, 6 insertions(+), 7
We are going to add a call to xtl_log.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/Makefile | 6 +++---
tools/libvchan/xenvchan.pc.in | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libvchan/Makefile
The point of this series is to make an API promise about what ENOENT
means from libxenvchan_client_init, to make it easier to build async
code on top of this (eg, libxl).
There is a lot of internal tidying, but also a necessary prefix is a
change to xentoollog to make it OK to pass NULL for a
These functions do in fact leave errno set. We are going to want to
use this.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/libxenvchan.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libvchan/libxenvchan.h
This is an integer type, not a pointer.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
tools/libvchan/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index ba5a6eb29e..180833dc2f 100644
--- a/tools/libvchan/init.c
+++
On 11/8/18 6:56 PM, George Dunlap wrote:
> On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
>> This patch is a pre-requisite for fixing the logdirty VGA issue
>> (display freezes when switching to a new altp2m view early in a
>> domain's lifetime), but sent separately for easier review.
>> The new
Delete 11 entirely formulaic conditional calls to
xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
and associated logger_tofree variables, error handling, etc.
No overall functional change, although some memory allocation errors
may no longer occur.
After this there are still several
No functional change.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
tools/xenstore/include/xenstore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstore/include/xenstore.h
b/tools/xenstore/include/xenstore.h
index 064b62c455..889dc23863 100644
---
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 November 2018 15:44
> To: 'Kevin Wolf'
> Cc: Stefano Stabellini ; qemu-bl...@nongnu.org;
> Tim Smith ; qemu-de...@nongnu.org; 'Markus
> Armbruster' ; Anthony
On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has been added to
On Thu, Nov 08, 2018 at 09:22:08AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 17:09, wrote:
> > On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 16:36, wrote:
> >> > On 08/11/18 15:33, Wei Liu wrote:
> >> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan
>>> On 08.11.18 at 14:20, wrote:
> On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 13:47, wrote:
>> > My point would be that on x86 I think the only way to have preemptible
>> > long-running operations inside of Xen is to block the guest vCPU and
>> > run them
>>> On 08.11.18 at 17:09, wrote:
> On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 16:36, wrote:
>> > On 08/11/18 15:33, Wei Liu wrote:
>> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> >> On 05.11.18 at 16:49, wrote:
>> On
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, unless perhaps sitting on an error path
next to a call which gets changed (in which case I think the error
path better remains consistent with the respective main path).
Signed-off-by: Jan Beulich
There's no need to go through an extra level of indirection. In order to
limit code churn, call sites using struct domain_iommu's platform_ops
don't get touched here, however.
Signed-off-by: Jan Beulich
---
v5: Re-base over dropped IOMMU_MIXED patch.
v4: New.
---
In preparation of allowing inline functions in asm/iommu.h to
de-reference struct struct iommu_ops, move the inclusion downwards past
the declaration of that structure. This in turn requires moving the
struct domain_iommu declaration, as it requires struct arch_iommu to be
fully declared
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by:
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 16:36, wrote:
> > On 08/11/18 15:33, Wei Liu wrote:
> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >> On 05.11.18 at 16:49, wrote:
> On 05/11/18 15:48, Wei Liu wrote:
> > On Mon,
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -185,7 +185,7 @@ void ctxt_switch_levelling(const struct
}
if
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls,
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent
While we don't mean to run their objtool over our generated code, it
still seems desirable to avoid calls to further functions before a
function's frame pointer is set up.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/arch/x86/efi/stub.c
+++
We don't need bigger alignment except when calling EFI boot or runtime
services functions (and we don't guarantee that either, as explained
close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
declaration). Hence if the compiler supports reducing stack alignment
from the ABI
flight 129514 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129514/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129405
test-armhf-armhf-libvirt 14
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific
On 11/8/18 5:53 PM, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
>> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
>>> On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
>>> wrote:
This patch adds a couple of regs to the vm_event that are used by
On Fri, Nov 02, 2018 at 01:37:28PM +0100, Juergen Gross wrote:
> Add the code for the Xen PVH mode boot entry.
>
> Signed-off-by: Juergen Gross
One nitpick below. Otherwise
Reviewed-by: Daniel Kiper
> ---
> V3: clear %fs and %gs, too (Daniel Kiper)
> use
On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> > On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >> This patch adds a couple of regs to the vm_event that are used by
> >> the introspection. The base, limit
>>> On 08.11.18 at 16:36, wrote:
> On 08/11/18 15:33, Wei Liu wrote:
>> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> On 05.11.18 at 16:49, wrote:
On 05/11/18 15:48, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> On 02.11.18
On Thu, Nov 08, 2018 at 08:39:36AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 16:33, wrote:
> > On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >> >>> On 05.11.18 at 16:49, wrote:
> >> > On 05/11/18 15:48, Wei Liu wrote:
> >> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 08 November 2018 15:21
> To: Paul Durrant
> Cc: 'Markus Armbruster' ; Anthony Perard
> ; Tim Smith ; Stefano
> Stabellini ; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Max Reitz ; xen-
>
On Fri, Nov 02, 2018 at 01:37:27PM +0100, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH. They will be filled
> with code later when the related functionality is being added.
>
> Signed-off-by: Juergen Gross
> ---
> V3: xenpvh->xen_pvh (Daniel Kiper)
> adjust
>>> On 08.11.18 at 16:38, wrote:
> On Thu, Nov 08, 2018 at 08:34:35AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 15:58, wrote:
>> > --- a/xen/arch/x86/cpu/amd.c
>> > +++ b/xen/arch/x86/cpu/amd.c
>> > @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>> >case 0xf ... 0x17:
On 08/11/18 15:33, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> On 05.11.18 at 16:49, wrote:
>>> On 05/11/18 15:48, Wei Liu wrote:
On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
On 02.11.18 at 16:55, wrote:
>> ---
On 08/11/2018 16:36, Daniel Kiper wrote:
> On Wed, Nov 07, 2018 at 03:49:51PM +0100, Juergen Gross wrote:
>> On 07/11/2018 13:21, Daniel Kiper wrote:
>>> On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
With Xen PVH mode adding a new machine type the machine related headers
>>> On 08.11.18 at 16:33, wrote:
> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> >>> On 05.11.18 at 16:49, wrote:
>> > On 05/11/18 15:48, Wei Liu wrote:
>> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
>> >> On 02.11.18 at 16:55, wrote:
>> ---
On Thu, Nov 08, 2018 at 08:34:35AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 15:58, wrote:
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> > case 0xf ... 0x17:
> > disable_c1e(NULL);
> >
On Wed, Nov 07, 2018 at 03:49:51PM +0100, Juergen Gross wrote:
> On 07/11/2018 13:21, Daniel Kiper wrote:
> > On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
> >> With Xen PVH mode adding a new machine type the machine related headers
> >> need to be present for the build to
>>> On 08.11.18 at 15:58, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> case 0xf ... 0x17:
> disable_c1e(NULL);
> if (acpi_smi_cmd && (acpi_enable_value |
1 - 100 of 148 matches
Mail list logo
