On 17.06.2021 06:55, Juergen Gross wrote:
> On 16.06.21 18:04, Jan Beulich wrote:
>> Since hypercalls from the tool stack are based on ioctl(), and since
>> ioctl() has a return type of "int", I'm afraid there's no way we can
>> deal with this by adjusting function return types in the libraries.
>>
On 16.06.2021 20:15, Andrew Cooper wrote:
> On 16/06/2021 17:04, Jan Beulich wrote:
>> All,
>>
>> several years back do_memory_op() in libxc was changed to have "long"
>> return type. This is because some of the sub-ops return potentially
>> large values as the hypercall return value (i.e. not in a
On 17.06.21 10:00, Jan Beulich wrote:
On 17.06.2021 06:55, Juergen Gross wrote:
On 16.06.21 18:04, Jan Beulich wrote:
Since hypercalls from the tool stack are based on ioctl(), and since
ioctl() has a return type of "int", I'm afraid there's no way we can
deal with this by adjusting function re
On 17.06.2021 10:05, Juergen Gross wrote:
> On 17.06.21 10:00, Jan Beulich wrote:
>> On 17.06.2021 06:55, Juergen Gross wrote:
>>> On 16.06.21 18:04, Jan Beulich wrote:
Since hypercalls from the tool stack are based on ioctl(), and since
ioctl() has a return type of "int", I'm afraid ther
flight 162870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
> From: Roger Pau Monne
> Sent: Saturday, May 29, 2021 1:40 AM
>
> This is an EPT specific function, so it shouldn't live in the generic
> mtrr file. Such movement is also needed for future work that will
> require passing a p2m_type_t parameter to epte_get_entry_emt, and
> making that type visib
On Wed, Jun 16, 2021 at 06:04:02PM +0200, Jan Beulich wrote:
> All,
>
> several years back do_memory_op() in libxc was changed to have "long"
> return type. This is because some of the sub-ops return potentially
> large values as the hypercall return value (i.e. not in an argument
> structure fiel
> From: Roger Pau Monne
> Sent: Saturday, May 29, 2021 1:40 AM
>
> Force WB type for grants and foreign pages. Those are usually mapped
> over unpopulated physical ranges in the p2m, and those ranges would
> usually be UC in the MTRR state, which is unlikely to be the correct
> cache attribute. I
On 17.06.21 11:26, Sander Eikelenboom wrote:
L.S.,
I just tried to upgrade and test the linux kernel going from the 5.12
kernel series to 5.13-rc6 on my homeserver with Xen, but ran in some
trouble.
Some VM's boot fine (with more than 256MB memory assigned), but the
smaller (memory wise) PV
flight 162869 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162869/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
Hi Olaf,
On 16/06/2021 17:02, Olaf Hering wrote:
Am Wed, 16 Jun 2021 15:50:24 +0100
schrieb Andrew Cooper :
new_max |= new_max >> 32;
Lazy compiler? I hoped this is a compile-time constant, which evaluates to zero
in 32bit builds.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id
On 15/06/2021 08:08, Penny Zheng wrote:
Hi julien
Hi Penny,
-Original Message-
From: Julien Grall
Sent: Wednesday, June 9, 2021 6:47 PM
To: Bertrand Marquis
Cc: Stefano Stabellini ; Julien Grall
; Penny Zheng ; xen-
de...@lists.xenproject.org; Wei Chen ; nd
Subject: Re: [PATCH 01/1
On 16/06/2021 16:38, Olaf Hering wrote:
> Am Wed, 16 Jun 2021 15:50:24 +0100
> schrieb Andrew Cooper :
>
>> 32bit toolstack build
> as in i386?
> How is this used in practice?
Every OSSTest run. Also, arm32 is absolutely a thing (the only reason
ARM can't migrate right now is because there is no
flight 162867 xen-unstable real [real]
flight 162873 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162867/
http://logs.test-lab.xenproject.org/osstest/logs/162873/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-win7-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xen
On Thu, Jun 17, 2021 at 09:31:28AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Saturday, May 29, 2021 1:40 AM
> >
> > Force WB type for grants and foreign pages. Those are usually mapped
> > over unpopulated physical ranges in the p2m, and those ranges would
> > usually be UC in
On 16.06.2021 17:43, Andrew Cooper wrote:
> On 16/06/2021 09:48, Jan Beulich wrote:
>> On 13.05.2021 22:15, Andrew Cooper wrote:
>>> On 13/05/2021 04:56, osstest service owner wrote:
flight 161917 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161917/
On 17.06.2021 13:40, Roger Pau Monné wrote:
> On Thu, Jun 17, 2021 at 09:31:28AM +, Tian, Kevin wrote:
>>> From: Roger Pau Monne
>>> Sent: Saturday, May 29, 2021 1:40 AM
>>>
>>> Force WB type for grants and foreign pages. Those are usually mapped
>>> over unpopulated physical ranges in the p2m
flight 162868 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162868/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 17/06/2021 12:30, Juergen Gross wrote:
On 17.06.21 11:26, Sander Eikelenboom wrote:
L.S.,
I just tried to upgrade and test the linux kernel going from the 5.12
kernel series to 5.13-rc6 on my homeserver with Xen, but ran in some
trouble.
Some VM's boot fine (with more than 256MB memory assi
On 16/06/2021 14:33, Bernhard M. Wiedemann wrote:
So this means, CentOS7 binutils has
9cb80f72d8b from 2011-12-21
but not
git blame binutils/objcopy.c|grep enable-determini
955d0b3bd75 (Roland McGrath 2013-01-07 17:40:59 + 549) -D
--enable-deterministic-archives\n\
2e30cb575a1 (Cary
flight 162875 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162875/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
Firstly, let me try to deal with substance and/or technical merit.
Jan, I am finding it difficult to follow in your message whether you
are asserting that your disputed change (to Xen) did not introduce a
vulnerability.
I think you are saying that there is no vulnerability, because in any
overall
On 17/06/2021 13:55, Michael Brown wrote:
one way out could be to call objcopy -D $PARAMS || objcopy $PARAMS
Testing on a clean "centos:7" container shows that "objcopy -D" works as
expected (and "objcopy --help" shows the option as existing).
This container environment has /etc/centos-relea
On 17.06.2021 15:05, Ian Jackson wrote:
> Firstly, let me try to deal with substance and/or technical merit.
>
> Jan, I am finding it difficult to follow in your message whether you
> are asserting that your disputed change (to Xen) did not introduce a
> vulnerability.
>
> I think you are saying
Jan Beulich writes ("Re: Regressed XSA-286, was [xen-unstable test] 161917:
regressions - FAIL"):
> If any OS made such an assumption, then I don't think it would be
> a vulnerability either. It would simply be a guest kernel bug then.
For the avoidance of doubt:
I think you are saying that if a
On 17.06.2021 16:49, Ian Jackson wrote:
> Jan Beulich writes ("Re: Regressed XSA-286, was [xen-unstable test] 161917:
> regressions - FAIL"):
>> If any OS made such an assumption, then I don't think it would be
>> a vulnerability either. It would simply be a guest kernel bug then.
>
> For the avo
Am Thu, 17 Jun 2021 12:24:22 +0100
schrieb Andrew Cooper :
> On 16/06/2021 16:38, Olaf Hering wrote:
> > Am Wed, 16 Jun 2021 15:50:24 +0100
> > schrieb Andrew Cooper :
> >
> >> 32bit toolstack build
> > as in i386?
> > How is this used in practice?
> Every OSSTest run.
This is not what I me
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
>
> I just tried to upgrade and test the linux kernel going from the 5.12 kernel
> series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble.
>
> Some VM's boot fine (with more than 256MB memory assigned), but the smaller
> (m
On Thu, Jun 17, 2021 at 10:03:50AM +0200, Jan Beulich wrote:
> But it's not just XENMEM_maximum_gpfn that's affected; that's just the
> one pointing out the underlying issue. Plus if so, shouldn't we avoid
> returning values that are going to be truncated (and, as can be seen
> here, then get perha
On 17/06/2021 15:55, Olaf Hering wrote:
> Am Thu, 17 Jun 2021 12:24:22 +0100
> schrieb Andrew Cooper :
>
>> On 16/06/2021 16:38, Olaf Hering wrote:
>>> Am Wed, 16 Jun 2021 15:50:24 +0100
>>> schrieb Andrew Cooper :
>>>
32bit toolstack build
>>> as in i386?
>>> How is this used in practice?
On 17.06.2021 17:03, Anthony PERARD wrote:
> On Thu, Jun 17, 2021 at 10:03:50AM +0200, Jan Beulich wrote:
>> But it's not just XENMEM_maximum_gpfn that's affected; that's just the
>> one pointing out the underlying issue. Plus if so, shouldn't we avoid
>> returning values that are going to be trunc
On 17.06.2021 10:08, Jan Beulich wrote:
> On 17.06.2021 10:05, Juergen Gross wrote:
>> On 17.06.21 10:00, Jan Beulich wrote:
>>> On 17.06.2021 06:55, Juergen Gross wrote:
On 16.06.21 18:04, Jan Beulich wrote:
> Since hypercalls from the tool stack are based on ioctl(), and since
> ioct
On Mon, May 24, 2021 at 4:37 PM Nick Rosbrook wrote:
>
> The primary goal of this patch series is to allow users of the xenlight
> package to manage a full domain life cycle. In particular, it provides
> support for receiving domain death events so that domain shutdown,
> reboot, destroy, etc. can
On 17/06/2021 17.01, Linus Torvalds wrote:
> On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom
> wrote:
>>
>> I just tried to upgrade and test the linux kernel going from the 5.12 kernel
>> series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble.
>>
>> Some VM's boot fine (with mo
On 17/06/2021 17.01, Linus Torvalds wrote:
> On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom
> wrote:
>>
>> I just tried to upgrade and test the linux kernel going from the 5.12 kernel
>> series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble.
>>
>> Some VM's boot fine (with mo
flight 162871 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored because do_lu_start() assumes
lu_status will be valid. This is not the case when Live-Update has been
Am Thu, 17 Jun 2021 13:02:39 +0200
schrieb Julien Grall :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
Thanks, comments in this bug suggest a workaround like this:
new_max |= sizeof(unsigned long) > 4 ? new_max >> 32 : 0;
This triggers no warning.
Olaf
pgp_UHxOqf9EC.pgp
Descriptio
On 17/06/2021 17:37, Rasmus Villemoes wrote:
On 17/06/2021 17.01, Linus Torvalds wrote:
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
I just tried to upgrade and test the linux kernel going from the 5.12 kernel
series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble
Hello,
Gitlab CI on 4.14 currently fails, e.g.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/322762306
The problem is that CentOS 6 (still supported back then) has Python 2.6
in it, and trips over the bug fixed by c/s 6d49fbdeab3e (4.15).
>From IRC,
20:18 < Diziet> andyhhp: gola
ou
boot a guest
were the kernel and initramfs get copied in from dom0, that works great, but
perhaps it
pokes around as the last part of the commit message warns about ?
(I think the feature was called "direct kernel boot", what I mean is using the
for example:
kernel = &
flight 162880 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162880/
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
On Thu, 17 Jun 2021, Jan Beulich wrote:
> GitlabCI doesn't tell me anything just yet, unless I go actively poll
> it. And as mentioned just yesterday on irc, I don't think I can easily
> navigate my way through those web pages, to find breakage I may have
> introduced and hence would better go fix.
flight 162878 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 162876 xen-unstable real [real]
flight 162883 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162876/
http://logs.test-lab.xenproject.org/osstest/logs/162883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 17/06/2021 19:24, Andrew Cooper wrote:
> Hello,
>
> Gitlab CI on 4.14 currently fails, e.g.
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/322762306
>
> The problem is that CentOS 6 (still supported back then) has Python 2.6
> in it, and trips over the bug fixed by c/s 6d49fbdea
Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
patch set is being split into two separate patch sets. This is the first
patch set and is focused purely on the clean up and refactoring of the
XSM hooks.
This patch set refactors the xsm_ops wrapper hooks to use the alternative_c
The assignment and setup of xsm_ops structure was refactored to make it a
one-time assignment. The calling of the xsm_ops were refactored to use the
alternate_call framework to reduce the need for retpolines.
Signed-off-by: Daniel P. Smith
---
xen/include/xsm/xsm.h| 206 -
On Thu, 17 Jun 2021, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
> ---
> kerne
On Thu, 17 Jun 2021, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
Acked-by
On Thu, 17 Jun 2021, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
Acked-by: St
On Thu, 17 Jun 2021, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
Acked-by: St
On Thu, 17 Jun 2021, Claire Chang wrote:
> Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
> support the memory allocation from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
On Thu, 17 Jun 2021, Claire Chang wrote:
> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> T
Multiple preprocessor defines were used as a mechanism to selective
include parts of the xsm.h header file. This makes it difficult to know
which portion is being included at anyone time. This commit works to
simplify this by separating the core structure and functions of XSM into
xsm-core.h away f
The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
and !CONFIG_XSM_FLASK
is whether the XSM hooks in dummy.h are called as static inline functions or as
function
pointers to static functions. As such this commit,
* eliminates CONFIG_XSM
* introduces CONFIG_XSM_EVTCHN_L
With the conversion of making XSM always enabled even the dummy XSM module is
being invoked through the xsm_ops dispatch which does not use passing of the
default privilege. This commit removes the xen_default_t parameter from the hook
definitions and all the respective call sites.
Signed-off-by:
With the elimination of switching how dummy.h gets included, the function
declaration macros are no longer necessary. This commit expands them out to the
only value for which they will ever be set. This results in function
declaration lengths changing and since some definitions did not even follow
With the eliminations of default priv from all the XSM hook call sites, this
renders the XSM_ASSERT_ACTION macro unneeded. This commit cleans up all the
dummy hooks, removing the macro.
Signed-off-by: Daniel P. Smith
---
xen/xsm/dummy.h | 253 +++-
1 f
Would like to add myself as a reviewer for XSM.
Signed-off-by: Daniel P. Smith
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d46b08a0d2..4f759867dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -622,6 +622,7 @@ F: xen/include/xen/trace.h
flight 162877 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162877/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Thu, 17 Jun 2021, Daniel P. Smith wrote:
> Would like to add myself as a reviewer for XSM.
>
> Signed-off-by: Daniel P. Smith
Acked-by: Stefano Stabellini
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d46b08a0d2..4f759867dc
quot;, what I mean is using the
for example:
kernel = '/boot/vmlinuz-5.13.0-rc6-20210617-doflr-mac80211debug+'
ramdisk = '/boot/initrd.img-5.13.0-rc6-20210617-doflr-mac80211debug+'
cmdline = 'root=UUID=2f757320-caca-4215-868d-73a4aacf12aa ro
nomo
flight 162879 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162879/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
wrote:
>
> On Thu, 17 Jun 2021, Claire Chang wrote:
> > Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> > initialization to make the code reusable.
> >
> > Signed-off-by: Claire Chang
> > Reviewed-by: Christoph Hellwig
>
66 matches
Mail list logo
