> -Original Message-
> From: Brian Marcotte
> Sent: 15 July 2020 20:17
> To: Durrant, Paul
> Cc: Jules ; xen-devel@lists.xenproject.org;
> oleksandr_gryt...@epam.com; w...@xen.org
> Subject: RE: [EXTERNAL] [Xen-devel] XEN Qdisk Ceph rbd support broken?
>
> CAUTION: This email originated
On Wed, Jul 15, 2020 at 02:13:42PM +0200, Jan Beulich wrote:
> On 15.07.2020 11:36, Roger Pau Monné wrote:
> > On Tue, Jul 07, 2020 at 09:39:40PM +0200, Michał Leszczyński wrote:
> >> @@ -1599,8 +1629,17 @@ long do_memory_op(unsigned long cmd,
> >> XEN_GUEST_HANDLE_PARAM(void) arg)
> >> #endif
>
Did you use internet during installation? The KVM package is available on the
DVD without the internet connection but Xen...
Sent from ProtonMail mobile
Original Message
On Jul 16, 2020, 11:02 AM, Jürgen Groß wrote:
> On 15.07.20 19:16, peter@protonmail.com wrote:
>>
>> He
On Tue, Jul 07, 2020 at 09:39:49PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
>
> Signed-off-by: Michal Leszczynski
> ---
> tools/libxc/Makefile | 1 +
> tools/libxc/include/xenctrl.h | 40
On Tue, Jul 07, 2020 at 09:39:50PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Add an demonstration tool that uses xc_vmtrace_* calls in order
^ a
> to manage external IPT monitoring for DomU.
>
> Signed-off-by: Michal Leszczynski
> ---
> tools/proctrace/Makefile|
From: Chen Huang
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Chen Huang
---
arch/x86/xen/p2m.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 4cf680e2e..0f4a449de 100644
--- a/arch/x86/xen/
On 15.07.2020 16:51, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 03:51:17PM +0200, Jan Beulich wrote:
>> On 15.07.2020 15:32, Roger Pau Monné wrote:
>>> Feel free to change to ACCESS_ONCE or barrier if you think it's
>>> clearer.
>>
>> I did so (also on the writer side), not the least based on
On 15.07.2020 16:37, George Dunlap wrote:
> IT sounds like you’re saying:
>
> 1. Paths listed without conditions will always be available
>
> 2. Paths listed with conditions may be extended: i.e., a node currently
> listed as PV might also become available for HVM guests
>
> 3. Paths listed wit
On Wed, Jul 15, 2020 at 12:03:57PM +0200, Jan Beulich wrote:
> Instead of checking inside the hook whether any non-coherent IOMMUs are
> present, simply install the hook only when this is the case.
>
> To prove that there are no other references to the now dynamically
> updated ops structure (and
On Wed, Jul 15, 2020 at 12:04:15PM +0200, Jan Beulich wrote:
> For full pages this is (meant to be) more efficient. Also change the
> type and reduce the scope of the involved local variable.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
flight 151935 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 16.07.2020 12:14, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 12:03:57PM +0200, Jan Beulich wrote:
>> Instead of checking inside the hook whether any non-coherent IOMMUs are
>> present, simply install the hook only when this is the case.
>>
>> To prove that there are no other references to
On 16.07.20 12:11, Jan Beulich wrote:
On 15.07.2020 16:37, George Dunlap wrote:
IT sounds like you’re saying:
1. Paths listed without conditions will always be available
2. Paths listed with conditions may be extended: i.e., a node currently listed
as PV might also become available for HVM gu
On Thu, Jul 16, 2020 at 12:06:14PM +0200, Jan Beulich wrote:
> On 15.07.2020 16:51, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 03:51:17PM +0200, Jan Beulich wrote:
> >> On 15.07.2020 15:32, Roger Pau Monné wrote:
> >>> Feel free to change to ACCESS_ONCE or barrier if you think it's
> >>> cl
On Thu, Jul 16, 2020 at 12:25:40PM +0200, Jan Beulich wrote:
> On 16.07.2020 12:14, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 12:03:57PM +0200, Jan Beulich wrote:
> >> Instead of checking inside the hook whether any non-coherent IOMMUs are
> >> present, simply install the hook only when th
On 16.07.2020 12:31, Roger Pau Monné wrote:
> On Thu, Jul 16, 2020 at 12:06:14PM +0200, Jan Beulich wrote:
>> On 15.07.2020 16:51, Roger Pau Monné wrote:
>>> On Wed, Jul 15, 2020 at 03:51:17PM +0200, Jan Beulich wrote:
On 15.07.2020 15:32, Roger Pau Monné wrote:
> Feel free to change to AC
On 16.07.2020 12:31, Jürgen Groß wrote:
> On 16.07.20 12:11, Jan Beulich wrote:
>> On 15.07.2020 16:37, George Dunlap wrote:
>>> IT sounds like you’re saying:
>>>
>>> 1. Paths listed without conditions will always be available
>>>
>>> 2. Paths listed with conditions may be extended: i.e., a node cu
flight 151926 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151926/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151884
Tests which did not succeed
On 16.07.20 13:24, Jan Beulich wrote:
On 16.07.2020 12:31, Jürgen Groß wrote:
On 16.07.20 12:11, Jan Beulich wrote:
On 15.07.2020 16:37, George Dunlap wrote:
IT sounds like you’re saying:
1. Paths listed without conditions will always be available
2. Paths listed with conditions may be exten
On Wed, Jul 15, 2020 at 12:15:10PM +0200, Jan Beulich wrote:
> Use ENXIO instead of EINVAL to cover the two cases of the address not
> satisfying the requirements. This will make an issue here better stand
> out at the call site.
Not sure whether I would use EFAULT instead of ENXIO, as the
descrip
On 16.07.2020 13:41, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 12:15:10PM +0200, Jan Beulich wrote:
>> Use ENXIO instead of EINVAL to cover the two cases of the address not
>> satisfying the requirements. This will make an issue here better stand
>> out at the call site.
>
> Not sure whethe
Hey all,
PDFs of the saved shared notes for the design sessions can be found in this
zipfile:
https://cryptpad.fr/file/#/2/file/LoJZpSq+vHKNoisVqdsPj3Z9/
The files are labeled with the start/end time and the room in which they were
held; that should help you find out the notes which are pertin
On 15.07.2020 16:02, Julien Grall wrote:
> On Wed, 15 Jul 2020, 14:42 Jan Beulich, wrote:
>
>> On 15.07.2020 12:46, Julien Grall wrote:
>>> On Wed, 15 Jul 2020, 12:17 Jan Beulich, wrote:
>>>
Neither the code nor the original commit provide any justification for
the need to 8-byte align
Requested-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -1,3 +1,22 @@
+# There are a few fundamentally different strategies for handling compat
+# (sub-)hypercalls:
+#
+# 1) Wrap a translation layer around the native hypercall. Structures
Add a trace event to follow devices attaching block drives:
$ qemu-system-arm -M n800 -trace blk_\*
9513@1594040428.738162:blk_attach_dev attaching blk 'sd0' to device
'omap2-mmc'
9513@1594040428.738189:blk_attach_dev attaching blk 'sd0' to device 'sd-card'
qemu-system-arm: sd_init failed
Let blk_attach_dev() take an Error* object to return helpful
information. Adapt the callers.
$ qemu-system-arm -M n800
qemu-system-arm: sd_init failed: cannot attach blk 'sd0' to device 'sd-card'
blk 'sd0' is already attached by device 'omap2-mmc'
Drive 'sd0' is already in use because it h
A pair of patches which helps me debug an issue with block
drive already attached.
Suggestions to correctly/better use the Error API welcome, in
particular in qdev-properties-system::set_drive_helper().
Since v1:
- Rebased after 668f62ec62 ("error: Eliminate error_propagate()")
Philippe Mathieu-
On 7/16/20 2:37 PM, Philippe Mathieu-Daudé wrote:
> Add a trace event to follow devices attaching block drives:
>
> $ qemu-system-arm -M n800 -trace blk_\*
> 9513@1594040428.738162:blk_attach_dev attaching blk 'sd0' to device
> 'omap2-mmc'
> 9513@1594040428.738189:blk_attach_dev attaching b
On Thu, Jul 16, 2020 at 02:37:04PM +0200, Philippe Mathieu-Daudé wrote:
> Let blk_attach_dev() take an Error* object to return helpful
> information. Adapt the callers.
>
> $ qemu-system-arm -M n800
> qemu-system-arm: sd_init failed: cannot attach blk 'sd0' to device 'sd-card'
> blk 'sd0' is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-329
version 2
Linux ioperm bitmap context switching issues
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Lin
> On Jul 16, 2020, at 12:34 PM, Jürgen Groß wrote:
>
> On 16.07.20 13:24, Jan Beulich wrote:
>> On 16.07.2020 12:31, Jürgen Groß wrote:
>>> On 16.07.20 12:11, Jan Beulich wrote:
On 15.07.2020 16:37, George Dunlap wrote:
> IT sounds like you’re saying:
>
> 1. Paths listed witho
On Wed, Jul 15, 2020 at 11:47:56AM +0200, Jan Beulich wrote:
> ... in order to also intercept accesses through the alias ports.
>
> Also stop intercepting accesses to the CMOS ports if we won't ourselves
> use the CMOS RTC.
I think you are missing the registration of the aliased ports in
rtc_init
On 16.07.20 16:20, George Dunlap wrote:
On Jul 16, 2020, at 12:34 PM, Jürgen Groß wrote:
On 16.07.20 13:24, Jan Beulich wrote:
On 16.07.2020 12:31, Jürgen Groß wrote:
On 16.07.20 12:11, Jan Beulich wrote:
On 15.07.2020 16:37, George Dunlap wrote:
IT sounds like you’re saying:
1. Paths l
flight 151930 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
test-amd64-amd64-e
On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich wrote:
> On 16.07.2020 13:41, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 12:15:10PM +0200, Jan Beulich wrote:
> >> Use ENXIO instead of EINVAL to cover the two cases of the address not
> >> satisfying the requirements. This will make an
On Thu, Jul 16, 2020 at 02:21:33PM +0200, Jan Beulich wrote:
> Requested-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks for writing this up!
On 16.07.2020 16:42, Roger Pau Monné wrote:
> On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich wrote:
>> On 16.07.2020 13:41, Roger Pau Monné wrote:
>>> On Wed, Jul 15, 2020 at 12:15:10PM +0200, Jan Beulich wrote:
Use ENXIO instead of EINVAL to cover the two cases of the address not
flight 151937 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151937/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d9269d69138860edb1ec9796ed48549dc6ba5735
baseline version:
ovmf e77966b341b993291ab2d
This reverts commit c436ff754810c15e4d2a434257d1d07498883acb.
Now that XSA-321 has been released we can try to enable PVH dom0
tests again.
Signed-off-by: Roger Pau Monné
---
make-flight | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/make-flight b/make-flight
index b25144f7
Signed-off-by: Nick Rosbrook
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e374816755..33fe51324e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -298,6 +298,7 @@ F: tools/debugger/gdbsx/
GOLANG BINDINGS
M: George Dunlap
+M: Nick R
> On Jul 16, 2020, at 5:00 PM, Nick Rosbrook wrote:
>
> Signed-off-by: Nick Rosbrook
Acked-by: George Dunlap
On Thu, 16 Jul 2020, 17:01 Jan Beulich, wrote:
> On 16.07.2020 16:42, Roger Pau Monné wrote:
> > On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich wrote:
> >> On 16.07.2020 13:41, Roger Pau Monné wrote:
> >>> On Wed, Jul 15, 2020 at 12:15:10PM +0200, Jan Beulich wrote:
> Use ENXIO instea
Hello All,
Following up on discussion on PCI Passthrough support on ARM that we had at the
XEN summit, we are submitting a Review For Comment and a design proposal for
PCI passthrough support on ARM. Feel free to give your feedback.
The followings describe the high-level design proposal of the
> Your issue stems from the auto-creation code in xen-block:
>
> The "aio:rbd:rbd/machine.disk0" string is generated by libxl and does
> look a little odd and will fool the parser there, but the error you see
> after modifying the string appears to be because QEMU's QMP block
> device instantiatio
On Thu, 16 Jul 2020, Rahul Singh wrote:
> Hello All,
>
> Following up on discussion on PCI Passthrough support on ARM that we had at
> the XEN summit, we are submitting a Review For Comment and a design proposal
> for PCI passthrough support on ARM. Feel free to give your feedback.
>
> The foll
flight 151939 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151939/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-s
flight 151934 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
151065
test-amd64-amd
> From: Jan Beulich
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> Instead of checking inside the hook whether any non-coherent IOMMUs are
> present, simply install the hook only when this is the case.
>
> To prove that there are no other references to the now dynamically
> updated ops structure (
> From: Jan Beulich
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> For full pages this is (meant to be) more efficient. Also change the
> type and reduce the scope of the involved local variable.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iomm
flight 151942 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151942/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151926
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 151946 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151946/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21a23e6966c2eb597a8db98d6837a4c01b3cad4a
baseline version:
ovmf d9269d69138860edb1ec9
Daniel P. Berrangé writes:
> On Thu, Jul 16, 2020 at 02:37:04PM +0200, Philippe Mathieu-Daudé wrote:
>> Let blk_attach_dev() take an Error* object to return helpful
>> information. Adapt the callers.
>>
>> $ qemu-system-arm -M n800
>> qemu-system-arm: sd_init failed: cannot attach blk 'sd0'
flight 151947 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151947/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151387
test-amd64-amd64-xl-qemuu-win7-amd64 17 g
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
testid debian-hvm-install
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 g
> On 16 Jul 2020, at 22:51, Stefano Stabellini wrote:
>
> On Thu, 16 Jul 2020, Rahul Singh wrote:
>> Hello All,
>>
>> Following up on discussion on PCI Passthrough support on ARM that we had at
>> the XEN summit, we are submitting a Review For Comment and a design proposal
>> for PCI passthr
55 matches
Mail list logo
