flight 133463 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 129313
flight 133471 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133471/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ece4c1de3e7b2340d351c2054c79ea689a954ed6
baseline version:
ovmf
Hi all,
[Thanks, Dan for the heads up and resolution.]
Today's linux-next merge of the nvdimm tree got a conflict in:
mm/memory_hotplug.c
between commit:
357b4da50a62 ("x86: respect memory size limiting via mem= parameter")
from the xen-tip tree and commit:
2794129e902d
flight 133462 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10
fail REGR. vs. 132748
flight 133458 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133410
flight 133461 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 19 guest-start.2fail REGR. vs. 133300
Tests which did
This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
still in the lasted mainline kernel.
This is obviated by new feature patch set ended with b672592f0221
("sched/cputime: Remove generic asm headers").
After xen guest is up for long time, once we hotplug new vcpu, the
On Wed, 27 Feb 2019, Jan Beulich wrote:
> >>> On 26.02.19 at 20:20, wrote:
> > On Tue, 26 Feb 2019, Ian Jackson wrote:
> >> Having written all that down (what a palaver), we can see that your
> >> cast, above, is a breach of the rules. Instead you can just pass the
> >> struct
flight 133485 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133485/
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
From: Igor Druzhinin
Date: Thu, 28 Feb 2019 14:11:26 +
> Occasionally, during the disconnection procedure on XenBus which
> includes hash cache deinitialization there might be some packets
> still in-flight on other processors. Handling of these packets includes
> hashing and hash cache
flight 133460 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133460/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133272
test-armhf-armhf-libvirt 14
On 2/28/19 2:45 PM, Andrew Morton wrote:
> On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
>
>> This series have been in -next for some days, could we get this in
>> mainline?
> It's been in -next for two months?
>
>> Andrew, do you have plan about them, maybe next release?
> They're all
On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
> This series have been in -next for some days, could we get this in
> mainline?
It's been in -next for two months?
> Andrew, do you have plan about them, maybe next release?
They're all reviewed except for "xen/balloon: mark inflated
This run is configured for baseline tests only.
flight 83681 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83681/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
It's not always clear what the best way is to handle unexpected
conditions: whether with ASSERT(), BUG_ON(), or some other method.
All methods have a risk of introducing security vulnerabilities and
unnecessary instabilities to production systems.
Document when to try to return an error for
flight 133456 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken in 133419
build-armhf
From: Igor Druzhinin
Date: Thu, 28 Feb 2019 12:48:03 +
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these
On 25/02/2019 13:16, Andrew Cooper wrote:
> The regression/ directory was identified as already broken in 2012 (c/s
> 953953cc5). The logic is intended to test *.py files in the Xen tree against
> different versions of python, but every identified version is now obsolete.
>
> Signed-off-by:
On 27/02/2019 12:31, Wei Liu wrote:
> On Mon, Feb 25, 2019 at 03:47:13PM +, Andrew Cooper wrote:
>> +
>> +switch ( data.idx )
>> +{
>> +/*
>> + * Assign data.val to 'field', checking for truncation if the
>> + * backing storage for 'field' is
On 28/02/2019 17:43, George Dunlap wrote:
> Gah -- sorry, Juergen, I pushed this series to staging erroneously; it
> wasn't targeted for 4.12 and doesn't have your release ack.
>
> Should I revert it?
With an x86 hat on, if this code is in a good state, I'd vote for it to
stay in. Accident
Gah -- sorry, Juergen, I pushed this series to staging erroneously; it
wasn't targeted for 4.12 and doesn't have your release ack.
Should I revert it?
-George
On Wed, Feb 27, 2019 at 11:10 AM Roger Pau Monne wrote:
>
> Current callers pass the p2m to paging_write_p2m_entry, but the
>
You'll get a better response rate if you actually cc' the tools maintainers.
-G
On Thu, Feb 28, 2019 at 4:22 PM Olaf Hering wrote:
>
> Am Thu, 28 Feb 2019 14:17:18 +0100
> schrieb Olaf Hering :
>
> > In domcreate_bootloader_done, libxl__build_pre is called.
> > If that function fails, the label
From: Paul Durrant
The locally allocated QDict-s need to be freed. ('file_layer' will be
freed implicitly since it is added as an object to 'driver_layer').
Spotted by Coverity: CID 1398649
While in the neighbourhood free 'driver' and 'filename' as soon as they are
added to the QDicts. Freeing
From: Paul Durrant
The function needs to make sure it is passed a valid disk name. This is
easily done by making sure that the parsing loop results in a non-zero
value.
Spotted by Coverity: CID 1398640
Reported-by: Peter Maydell
Signed-off-by: Paul Durrant
Acked-by: Anthony PERARD
From: Paul Durrant
The assignment to 'p' is unnecessary as the code will either goto 'invalid'
or p will get overwritten.
Spotted by Coverity: CID 1398638
Reported-by: Peter Maydell
Signed-off-by: Paul Durrant
Acked-by: Anthony PERARD
Message-Id:
-dm.git
tags/pull-xen-20190228
for you to fetch changes up to 156ac94463b42b0b9beea263af9866dfcd3683e0:
xen-block: stop leaking memory in xen_block_drive_create() (2019-02-28
17:21:12 +)
Xen queue
* xen-block fixes
From: Paul Durrant
The if() statement is clearly bogus (dead code which should have been
cleaned up when grant mapping was removed).
Spotted by Coverity: CID 1398635
While in the neighbourhood, add a missing 'fall through' annotation.
Reported-by: Peter Maydell
Signed-off-by: Paul Durrant
On 2/27/19 11:09 AM, Roger Pau Monne wrote:
> Current npt and shadow code to get an entry will always return
> INVALID_MFN for foreign entries. Allow to return the entry mfn for
> foreign entries, like it's done for grant table entries.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Jan
On 2/27/19 11:09 AM, Roger Pau Monne wrote:
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
>
> This commit also removes the check that prevent non-ept PVH dom0 from
> mapping foreign pages.
>
> Signed-off-by: Roger Pau Monné
On 2/27/19 11:30 AM, Roger Pau Monne wrote:
> This is in preparation for also changing p2m_entry_modify to return an
> error code.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: George Dunlap
___
Xen-devel
flight 133478 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133478/
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 2/26/19 9:17 AM, Alexandru Stefan ISAILA wrote:
> Ping. Is this ok with you, George?
Sorry -- somehow I thought I'd responded to this, but apparently not.
> On 17.01.2019 11:06, Alexandru Stefan ISAILA wrote:
>> Changed the return value of 1 to 0 so now p2m_finish_type_change returns
>> 0 for
Am Thu, 28 Feb 2019 14:17:18 +0100
schrieb Olaf Hering :
> In domcreate_bootloader_done, libxl__build_pre is called.
> If that function fails, the label 'out:' is called, which goes straight into
> domcreate_stream_done. This function uses srs->dcs to set
> libxl__domain_create_state.
> In my
flight 133451 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133451/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-arm64-xsm
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 28 February 2019 14:11
> To: xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: Wei Liu ; Paul Durrant ;
> da...@davemloft.net; Igor
> Druzhinin
> Subject:
Hi,
On 2/26/19 11:07 PM, Stefano Stabellini wrote:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 73
Occasionally, during the disconnection procedure on XenBus which
includes hash cache deinitialization there might be some packets
still in-flight on other processors. Handling of these packets includes
hashing and hash cache population that finally results in hash cache
data structure corruption.
Am Thu, 28 Feb 2019 14:17:18 +0100
schrieb Olaf Hering :
> In domcreate_bootloader_done, libxl__build_pre is called.
> If that function fails, the label 'out:' is called, which goes straight into
> domcreate_stream_done. This function uses srs->dcs to set
> libxl__domain_create_state.
> In my
Signed-off-by: Wei Liu
---
automation/gitlab-ci/build-each-commit.sh | 16
1 file changed, 16 insertions(+)
create mode 100755 automation/gitlab-ci/build-each-commit.sh
diff --git a/automation/gitlab-ci/build-each-commit.sh
b/automation/gitlab-ci/build-each-commit.sh
new file
This helps shorten turn-around time.
---
.gitlab-ci.yml | 4 +--
automation/gitlab-ci/test.yaml | 68 --
2 files changed, 2 insertions(+), 70 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c8bd7519d5..72ff9136ce 100644
---
`git rev-list` can fail if the base..tip range contains invalid
commit(s). If that happens ret never gets a chance to be set.
Set ret before hand to fix the issue.
Signed-off-by: Wei Liu
---
automation/scripts/build-test.sh | 1 +
1 file changed, 1 insertion(+)
diff --git
Signed-off-by: Wei Liu
---
automation/scripts/build-test.sh | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/automation/scripts/build-test.sh b/automation/scripts/build-test.sh
index c318b65d5a..206a4f9a4a 100755
--- a/automation/scripts/build-test.sh
+++
This is added to the test stage so that its failure won't block other
things.
Signed-off-by: Wei Liu
---
Note: this patch will look different when it is applied to staging,
but you can see the core idea here.
---
automation/gitlab-ci/test.yaml | 7 ---
1 file changed, 4 insertions(+), 3
We have a requirement to make each commit buildable in xen.git. Put this
into a test in Gitlab CI.
Wei Liu (5):
automation: allow build-test.sh to run in detached HEAD state
automation: set ret for potential error in build-test.sh
automation: add a script to build newly pushed commits in
flight 133465 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133465/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a4698202cf5ca81d4401bdc6c0974400064f333
baseline version:
ovmf
On 28/02/2019 10:39, Jan Beulich wrote:
On 27.02.19 at 13:07, wrote:
>> On 27/02/2019 10:02, Jan Beulich wrote:
>>>
>>> Reviewed-by: Jan Beulich
>>> albeit ...
>>>
@@ -323,6 +326,15 @@ static void setup_p6_watchdog(unsigned counter)
unsigned int evntsel;
On 28/02/2019 13:51, Andrew Cooper wrote:
> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
> c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have a
> suitable prototype in the !CONFIG_HVM case.
>
> Introduce one to fix the build.
>
> Spotted by
On 28/02/2019 12:51, Andrew Cooper wrote:
> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
Lovely, and git too out the line starting with #VE here.
I'll adjust suitably on commit.
~Andrew
> c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have
On Thu, Feb 28, 2019 at 01:18:10PM +, Andrew Cooper wrote:
> On 28/02/2019 12:53, Wei Liu wrote:
> > On Thu, Feb 28, 2019 at 12:51:12PM +, Andrew Cooper wrote:
> >> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
> >> c/s e72ecc761541 "x86/altp2m: Rework #VE
In domcreate_bootloader_done, libxl__build_pre is called.
If that function fails, the label 'out:' is called, which goes straight into
domcreate_stream_done. This function uses srs->dcs to set
libxl__domain_create_state.
In my case ->dcs is NULL. The result is a crash in STATE_AO_GC().
How can
On 28/02/2019 12:53, Wei Liu wrote:
> On Thu, Feb 28, 2019 at 12:51:12PM +, Andrew Cooper wrote:
>> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
>> c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have a
>> suitable prototype in the
>>> On 28.02.19 at 13:51, wrote:
> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
> c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have a
> suitable prototype in the !CONFIG_HVM case.
>
> Introduce one to fix the build.
>
> Spotted by Travis.
On Thu, Feb 28, 2019 at 12:51:12PM +, Andrew Cooper wrote:
> c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
> c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have a
> suitable prototype in the !CONFIG_HVM case.
>
> Introduce one to fix the
On Thu, Feb 28, 2019 at 12:48:03PM +, Igor Druzhinin wrote:
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these
c/s 0ec9b4ef3148 "x86/vmx: Fix security issue when a guest balloons out the
c/s e72ecc761541 "x86/altp2m: Rework #VE enable/disable paths" didn't have a
suitable prototype in the !CONFIG_HVM case.
Introduce one to fix the build.
Spotted by Travis.
Signed-off-by: Andrew Cooper
---
CC: Jan
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the
On Thu, Feb 28, 2019 at 11:08:37AM +0100, Roger Pau Monné wrote:
> On Mon, Feb 25, 2019 at 12:14:02AM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Dec 17, 2018 at 05:09:19PM +0100, Roger Pau Monné wrote:
> > > On Mon, Dec 17, 2018 at 02:42:23PM +, Paul Durrant wrote:
> > > > I suspect
On Thu, Feb 28, 2019 at 12:07:07PM +, Paul Durrant wrote:
> Yes, I meant kfree_skb(nskb).
>
In that case I think your patch looks fine.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Thu, Feb 28, 2019 at 03:58:37AM -0700, Jan Beulich wrote:
> >>> On 27.02.19 at 16:05, wrote:
> > On Wed, Feb 27, 2019 at 04:41:37AM -0700, Jan Beulich wrote:
> >> >>> On 07.02.19 at 01:07, wrote:
> >> > +int msi_msix_set_enable(struct pci_dev *pdev, int mode, int enable)
> >> > +{
> >> > +
flight 133448 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133448/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-armhf
flight 83679 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/83679/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 27.02.19 at 17:13, wrote:
> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
> L1 cache is problematic, because when hyperthreading is used as well, a
> guest running on the sibling core can leak this potentially secret data.
>
> To prevent these speculative
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 28 February 2019 11:22
> To: Wei Liu
> Cc: Igor Druzhinin ; Wei Liu
> ; net...@vger.kernel.org;
> linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org;
>
+Xen-devel list
On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’:
On 28/02/2019 11:21, Paul Durrant wrote:
>>> @@ -1153,6 +1152,10 @@ static int xenvif_tx_submit(struct xenvif_queue
>>> *queue)
>>> kfree_skb(skb);
>>> continue;
>>> }
>>> +
>>> + /*
On Thu, Feb 28, 2019 at 03:50:14AM -0700, Jan Beulich wrote:
> >>> On 27.02.19 at 16:18, wrote:
> > On Wed, Feb 27, 2019 at 04:07:54AM -0700, Jan Beulich wrote:
> >> >>> On 08.02.19 at 11:17, wrote:
> >> > @@ -190,19 +190,19 @@ int create_irq(nodeid_t node)
> >> > desc->arch.used =
On 27/02/2019 12:51, Roger Pau Monne wrote:
> Current check for MSI EIO is missing a special case for PVH Dom0,
> which doesn't have a hvm_irq_dpci struct but requires EIOs to be
> forwarded to the physical lapic for passed-through devices.
>
> Add a short-circuit to allow EOIs from PVH Dom0 to
On 25/02/2019 11:39, George Dunlap wrote:
> On Fri, Feb 22, 2019 at 7:15 PM Andrew Cooper
> wrote:
>> iremap_maddr and qinval_maddr point to the base of a block of contiguous RAM,
>> allocated by the driver, holding the Interrupt Remapping table, and the
>> Queued
>> Invalidation ring.
>>
>>
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 28 February 2019 11:02
> To: Paul Durrant
> Cc: Igor Druzhinin ;
> xen-devel@lists.xenproject.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; Wei Liu
> ;
> da...@davemloft.net
> Subject: Re: [PATCH]
>>> On 27.02.19 at 12:51, wrote:
> Current check for MSI EIO is missing a special case for PVH Dom0,
> which doesn't have a hvm_irq_dpci struct but requires EIOs to be
> forwarded to the physical lapic for passed-through devices.
>
> Add a short-circuit to allow EOIs from PVH Dom0 to be
>>> On 28.02.19 at 11:58, wrote:
> I think you mean "Increase" in the subject line.
>
> On Thu, Feb 28, 2019 at 10:48:53AM +, Andrew Cooper wrote:
>> At INFO level, it doesn't get printed out by default in release builds,
>> leading to unqualified logging such as this:
>>
>> (XEN) [
> On Feb 25, 2019, at 11:20 PM, Rich Persaud wrote:
>
> On Feb 25, 2019, at 10:14, George Dunlap wrote:
>>
>> This is an attempt to do a 'post-mortem' on XSA-283, to find out how
>> the error came about, and consider what changes we could make to code
>> / processes to prevent such errors
On Thu, Feb 28, 2019 at 09:46:57AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> > Sent: 28 February 2019 02:03
> > To: xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> > linux-ker...@vger.kernel.org
> > Cc: Wei
On 28/02/2019 11:48, Andrew Cooper wrote:
> At INFO level, it doesn't get printed out by default in release builds,
> leading to unqualified logging such as this:
>
> (XEN) [ 66.995993] Freed 524kB init memory
> (XEN) [ 1993.144997] *** Dumping Dom9 vcpu#2 state: ***
> (XEN) [
On 28/02/2019 10:58, Wei Liu wrote:
> I think you mean "Increase" in the subject line.
I do, fixed.
>
> On Thu, Feb 28, 2019 at 10:48:53AM +, Andrew Cooper wrote:
>> At INFO level, it doesn't get printed out by default in release builds,
>> leading to unqualified logging such as this:
>>
>>
>>> On 27.02.19 at 16:05, wrote:
> On Wed, Feb 27, 2019 at 04:41:37AM -0700, Jan Beulich wrote:
>> >>> On 07.02.19 at 01:07, wrote:
>> > +int msi_msix_set_enable(struct pci_dev *pdev, int mode, int enable)
>> > +{
>> > +int ret;
>> > +
>> > +ret = xsm_msi_set_enable(XSM_DM_PRIV,
I think you mean "Increase" in the subject line.
On Thu, Feb 28, 2019 at 10:48:53AM +, Andrew Cooper wrote:
> At INFO level, it doesn't get printed out by default in release builds,
> leading to unqualified logging such as this:
>
> (XEN) [ 66.995993] Freed 524kB init memory
> (XEN) [
>>> On 27.02.19 at 16:18, wrote:
> On Wed, Feb 27, 2019 at 04:07:54AM -0700, Jan Beulich wrote:
>> >>> On 08.02.19 at 11:17, wrote:
>> > @@ -190,19 +190,19 @@ int create_irq(nodeid_t node)
>> > desc->arch.used = IRQ_UNUSED;
>> > irq = ret;
>> > }
>> > -else if (
At INFO level, it doesn't get printed out by default in release builds,
leading to unqualified logging such as this:
(XEN) [ 66.995993] Freed 524kB init memory
(XEN) [ 1993.144997] *** Dumping Dom9 vcpu#2 state: ***
(XEN) [ 1993.145008] [ Xen-4.11.1 x86_64 debug=n Not tainted
>>> On 28.02.19 at 01:05, wrote:
> On Wed, 27 Feb 2019, Jan Beulich wrote:
>> >>> On 26.02.19 at 19:43, wrote:
>> > On Tue, 26 Feb 2019, Ian Jackson wrote:
>> >> Jan Beulich writes ("Re: [PATCH v10 2/6] xen: introduce DEFINE_SYMBOL"):
>> >> > On 26.02.19 at 17:46, wrote:
>> >> > > I am not
>>> On 27.02.19 at 18:34, wrote:
> Would you be able to follow my suggested approach?
I guess so. Some of the context should really have been provided before
the patches were posted, though. And I still think we will want to have an
overall picture of the impact on the code base, even if
On Mon, Feb 25, 2019 at 12:14:02AM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Dec 17, 2018 at 05:09:19PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 17, 2018 at 02:42:23PM +, Paul Durrant wrote:
> > > I suspect I must be remembering a XenServer-specific hack^Wpatch then.
> > > I'd
>>> On 27.02.19 at 14:01, wrote:
> On 2/25/19 17:46, Jan Beulich wrote:
>> I would really like to ask that I (or someone else) don't need to
>> go through and list remaining version checks again - after all I
>> had done so for v6 already, and I didn't go through all of them
>> again for v7
flight 133447 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133447/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-i386
On 28/02/2019 02:03, Igor Druzhinin wrote:
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these fragments. Those
On Wed, Feb 27, 2019 at 12:26:19AM +, tosher 1 wrote:
> Hi Guys,
> Lately, I have been trying to play with Xen Driver Domain. I have been able
> to make it work where both the Driver Domain OS and the guest OS are run on
> paravirtualized (PV) machine. However, it doesn't work when any of
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 28 February 2019 02:03
> To: xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: Wei Liu ; Paul Durrant ;
> da...@davemloft.net; Igor
> Druzhinin
> Subject:
>>> On 27.02.19 at 13:07, wrote:
> On 27/02/2019 10:02, Jan Beulich wrote:
>>
>> Reviewed-by: Jan Beulich
>> albeit ...
>>
>>> @@ -323,6 +326,15 @@ static void setup_p6_watchdog(unsigned counter)
>>> unsigned int evntsel;
>>>
>>> nmi_perfctr_msr = MSR_P6_PERFCTR(0);
>>> +if (
This run is configured for baseline tests only.
flight 83677 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83677/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 133443 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133443/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-armhf-pvops
90 matches
Mail list logo
