Hi Roman,
Good catch.
GPU works now and I can start X! Thanks! I was also able to create domU
that runs Raspian OS.
This is very interesting that you were able to achieve that - congrats!
Now, sorry to be a bit dense -- but since this thread went into all
sorts of interesting
directions all
On 01.02.2021 13:43, Jan Beulich wrote:
> As per the comment ahead of it, the original purpose of the function was
> to deal with TSCs halted in deep C states. While this probably explains
> why only forward moves were ever expected, I don't see how this could
> have been reliable in case CPU0 was
On 01.02.2021 19:26, Andrew Cooper wrote:
> On 01/02/2021 16:20, Jan Beulich wrote:
>> Xen is heavily relying on the DCE stage to remove unused code so the
>> linker doesn't throw an error because a function is not implemented
>> yet we defined a prototype for it.
>>
>> On some GCC versions (such a
> -Original Message-
> From: Igor Druzhinin
> Sent: 02 February 2021 00:20
> To: Andrew Cooper ; Tamas K Lengyel
> ; Xen-devel
> ; Wei Liu ; Ian Jackson
> ; Anthony
> PERARD ; Paul Durrant
> Subject: Re: staging: unable to restore HVM with Viridian param set
>
> n 01/02/2021 22:57, And
On 02.02.2021 00:35, Andrew Cooper wrote:
> This diff is easier viewed through `cat -A`
>
> diff --git a/tools/xenstore/include/xenstore_state.h
> b/tools/xenstore/include/xenstore_state.h$
> index 1bd443f61a..f7e4da2b2c 100644$
> --- a/tools/xenstore/include/xenstore_state.h$
> +++ b/too
On 02.02.2021 00:26, Andrew Cooper wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -132,6 +132,56 @@ static void vcpu_info_reset(struct vcpu *v)
> v->vcpu_info_mfn = INVALID_MFN;
> }
>
> +static void vmtrace_free_buffer(struct vcpu *v)
> +{
> +const struct domain *d
On Mon, Feb 01, 2021 at 11:35:13PM +, Andrew Cooper wrote:
> This diff is easier viewed through `cat -A`
>
> diff --git a/tools/xenstore/include/xenstore_state.h
> b/tools/xenstore/include/xenstore_state.h$
> index 1bd443f61a..f7e4da2b2c 100644$
> --- a/tools/xenstore/include/xenstore_s
> -Original Message-
> From: Xen-devel On Behalf Of Dongli
> Zhang
> Sent: 30 January 2021 05:09
> To: p...@xen.org; 'Jürgen Groß' ;
> xen-devel@lists.xenproject.org; linux-
> bl...@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: 'Paul Durrant' ; 'Konrad Rzeszutek Wilk'
> ; 'Roger P
flight 158944 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158804
build-arm64-
flight 158915 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl-seattle
flight 158946 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158804
build-arm64-
Fix the following coccicheck warnings:
./drivers/net/xen-netfront.c:1816:52-54: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xe
Andrew Cooper writes ("[PATCH] xenstore: Fix all builds"):
> This diff is easier viewed through `cat -A`
...
> A non-breaking space isn't a valid C preprocessor token.
Yikes.
Thanks!
Ian.
On 02/02/2021 08:35, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 02 February 2021 00:20
>> To: Andrew Cooper ; Tamas K Lengyel
>> ; Xen-devel
>> ; Wei Liu ; Ian Jackson
>> ; Anthony
>> PERARD ; Paul Durrant
>> Subject: Re: staging: unable to restore HVM wi
Igor Druzhinin writes ("Re: staging: unable to restore HVM with Viridian param
set"):
> On 02/02/2021 08:35, Paul Durrant wrote:
> > Surely it should be addressed properly in libxl by not messing with the
> > viridian settings on migrate-in/resume, as Andrew says? TBH I thought this
> > was alre
On 02/02/2021 11:51, Ian Jackson wrote:
> Igor Druzhinin writes ("Re: staging: unable to restore HVM with Viridian
> param set"):
>> On 02/02/2021 08:35, Paul Durrant wrote:
>>> Surely it should be addressed properly in libxl by not messing with the
>>> viridian settings on migrate-in/resume, as
On 01.02.21 16:00, Andrew Cooper wrote:
Hi Andrew
On 01/02/2021 13:47, Oleksandr wrote:
On 01.02.21 15:07, Andrew Cooper wrote:
Hi Andrew
On 01/02/2021 12:34, Oleksandr wrote:
On 30.01.21 04:58, Andrew Cooper wrote:
One query I did leave on IRC, and hasn't had an answer.
What is the ma
Andrew Cooper writes ("[PATCH v9 03/11] tools/[lib]xl: Add vmtrace_buf_size
parameter"):
> From: Michał Leszczyński
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
...
Wearing my maintainer/reviewer hat:
Release ris
Ian Jackson writes ("Re: [PATCH v9 03/11] tools/[lib]xl: Add vmtrace_buf_size
parameter"):
> Andrew Cooper writes ("[PATCH v9 03/11] tools/[lib]xl: Add vmtrace_buf_size
> parameter"):
> > From: Michał Leszczyński
> >
> > Allow to specify the size of per-vCPU trace buffer upon
> > domain creatio
Andrew Cooper writes ("[PATCH v9 00/11] acquire_resource size and external IPT
monitoring"):
...
> Therefore, I'd like to request a release exception.
Thanks for this writeup.
There is discussion here of the upside of granting an exception, which
certainly seems substantial enough to give this s
On 02/02/2021 12:20, Ian Jackson wrote:
> Since you mentioned patch 1 and asserted it didn't need a release-ack,
> I looked at it in a little more detail. It seems to contain a
> moderate amount of (fairly localised) restructuring. IDK whether
> XENMEM_acquire_resource is used by non-IPT configur
flight 158950 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158950/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-coresched-i386-xl
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
T
flight 158922 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158922/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 16 guest-saverestore fail pass in 158873
test-armhf-armhf-libvirt-raw 13
On Tue, 2021-02-02 at 07:59 +, Julien Grall wrote:
> Hi Dario,
>
Hi!
> I have had a quick look at your place. The RCU call in
> leave_hypervisor_to_guest() needs to be placed just after the last
> call
> to check_for_pcpu_work().
>
> Otherwise, you may be preempted and keep the RCU quiet.
I'm sorry it took so long to prepare v2. I had some trouble
figuring a reasonable way to address the main earlier review
requests in what is now patch 2; see there for what changed.
Patch 1 is new.
1: fix waiting for broadcast completion
2: refine when to send mapcache invalidation request
Jan
Checking just a single server is not enough - all of them must have
signaled that they're done processing the request.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/common/ioreq.c
+++ b/xen/common/ioreq.c
@@ -213,9 +213,9 @@ bool vcpu_ioreq_handle_completion(struct
return false;
XENMEM_decrease_reservation isn't the only means by which pages can get
removed from a guest, yet all removals ought to be signaled to qemu. Put
setting of the flag into the central p2m_remove_page() underlying all
respective hypercalls as well as a few similar places, mainly in PoD
code.
Addition
(Adding Andrew, Jan, Juergen for visibility)
Hi Dario,
On 02/02/2021 15:03, Dario Faggioli wrote:
On Tue, 2021-02-02 at 07:59 +, Julien Grall wrote:
Hi Dario,
I have had a quick look at your place. The RCU call in
leave_hypervisor_to_guest() needs to be placed just after the last
call
to
On 02/02/2021 07:09, Juergen Gross wrote:
> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> xenvif_rx_ring_slots_available() is no longer called only from the rx
> queue kernel thread, so it needs to access the rx queue with the
> associated queue held.
>
> Reported-by: I
'drivers_blacklisted' is never accessed, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen_platform.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index 7c4db35debb..01ae1fb1618 10064
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 02 February 2021 15:57
> To: qemu-de...@nongnu.org
> Cc: Richard Henderson ; Paolo Bonzini
> ; Eduardo
> Habkost ; qemu-triv...@nongnu.org; Michael S. Tsirkin
> ; Marcel
> Apfelbaum ; xen-devel@lists.xenproject.org; Paul
> Durr
Hello Stefano,
> On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> wrote:
>
> From: Brian Woods
>
> Modify the smmu driver so that it uses the iommu_fwspec helper
> functions. This means both ARM IOMMU drivers will both use the
> iommu_fwspec helper functions, making enabling generic device
Hello Stefano,
> On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> wrote:
>
> Hi all,
>
> This series introduces support for the generic SMMU bindings to
> xen/drivers/passthrough/arm/smmu.c.
>
> The last version of the series was
> https://marc.info/?l=xen-devel&m=159539053406643
>
> I real
Hello Stefano,
> On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> wrote:
>
> From: Brian Woods
>
> Now that all arm iommu drivers support generic bindings we can remove
> the workaround from iommu_add_dt_device().
>
> Note that if both legacy bindings and generic bindings are present in
> d
Hello Stefano,
> On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> wrote:
>
> From: Brian Woods
>
> Restructure some of the code and add supporting functions for adding
> generic device tree (DT) binding support. This will allow for using
> current Linux device trees with just modifying the
On 02.02.21 16:26, Igor Druzhinin wrote:
On 02/02/2021 07:09, Juergen Gross wrote:
Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
xenvif_rx_ring_slots_available() is no longer called only from the rx
queue kernel thread, so it needs to access the rx queue with the
associ
On Tue, Feb 02, 2021 at 08:09:38AM +0100, Juergen Gross wrote:
> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> xenvif_rx_ring_slots_available() is no longer called only from the rx
> queue kernel thread, so it needs to access the rx queue with the
> associated queue held
On Thu, Jan 28, 2021 at 01:04:41PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
> behaviour of xen-blkback when connecting to a frontend was
flight 158932 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158932/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3b468095cd3dfcd1aa4ae63bc623f534bc2390d2
baseline version:
ovmf ea56ebf67dd55483105aa
On 02/02/21 16:56, Philippe Mathieu-Daudé wrote:
'drivers_blacklisted' is never accessed, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen_platform.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xe
> -Original Message-
> From: Roger Pau Monné
> Sent: 02 February 2021 16:29
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Paul
> Durrant ; Konrad Rzeszutek Wilk
> ; Jens Axboe
> ; Dongli Zhang
> Subject: Re: [PATCH
On 1/22/21 6:51 AM, Jan Beulich wrote:
> Also, Andrew, (I think I did say so before) - I definitely
> would want your general consent with this model, as what gets
> altered here is almost all relatively recent contributions
> by you. Nor would I exclude the approach being controversial.
>
Andre
flight 158929 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158929/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 158898
test-arm64-arm64-xl-credit2
On Tue, 2 Feb 2021, Rahul Singh wrote:
> Hello Stefano,
>
> > On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> > wrote:
> >
> > Hi all,
> >
> > This series introduces support for the generic SMMU bindings to
> > xen/drivers/passthrough/arm/smmu.c.
> >
> > The last version of the series was
>
The handle_device() function has been returning failure upon
encountering a device address which was invalid. A device tree which
had such an entry has now been seen in the wild. As it causes no
failures to simply ignore the entries, ignore them.
Signed-off-by: Elliott Mitchell
---
I'm startin
Hi,
On 02/02/2021 17:44, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Rahul Singh wrote:
Hello Stefano,
On 26 Jan 2021, at 10:58 pm, Stefano Stabellini wrote:
Hi all,
This series introduces support for the generic SMMU bindings to
xen/drivers/passthrough/arm/smmu.c.
The last version of t
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a frontend was:
- read 'ring-page-order'
- if not present then expect a single page r
Hi,
On 02/02/2021 17:47, Elliott Mitchell wrote:
The handle_device() function has been returning failure upon
encountering a device address which was invalid. A device tree which
had such an entry has now been seen in the wild. As it causes no
failures to simply ignore the entries, ignore them
On Tue, 2 Feb 2021, Julien Grall wrote:
> On 02/02/2021 17:44, Stefano Stabellini wrote:
> > On Tue, 2 Feb 2021, Rahul Singh wrote:
> > > Hello Stefano,
> > >
> > > > On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
> > > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > This series introduces su
Hello,
on NetBSD I'm tracking down an issue where xenstored never closes its
file descriptor to /var/run/xenstored/socket and instead loops at 100%
CPU on these descriptors.
xenstored loops because poll(2) returns a POLLIN event for these
descriptors but they are marked is_ignored = true.
I'm se
Hi Stefano,
On 02/02/2021 18:27, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Julien Grall wrote:
On 02/02/2021 17:44, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Rahul Singh wrote:
Hello Stefano,
On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
wrote:
Hi all,
This series introduces su
For now, simply try to map 40 frames of grant table. This catches most of the
basic errors with resource sizes found and fixed through the 4.15 dev window.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC
On 02/02/2021 18:12, Julien Grall wrote:
Hi,
On 02/02/2021 17:47, Elliott Mitchell wrote:
The handle_device() function has been returning failure upon
encountering a device address which was invalid. A device tree which
had such an entry has now been seen in the wild. As it causes no
failu
On 02/02/2021 12:20, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v9 00/11] acquire_resource size and external
> IPT monitoring"):
> ...
>> Therefore, I'd like to request a release exception.
> Thanks for this writeup.
>
> There is discussion here of the upside of granting an exception, whic
This is a Request For Comments on the adoption of Device Tree as the
format for the Launch Control Module as described in the previously
posted DomB RFC.
For RFC purposes, a rendered of this file can be found here:
ihttps://drive.google.com/file/d/1l3fo4FylvZCQs1V00DcwifyLjl5Jw3W8/view?usp=sharing
On Tue, 2 Feb 2021, Jukka Kaartinen wrote:
> Hi Roman,
>
> > > >
> > > Good catch.
> > > GPU works now and I can start X! Thanks! I was also able to create domU
> > > that runs Raspian OS.
> >
> > This is very interesting that you were able to achieve that - congrats!
> >
> > Now, sorry to be a
On Tue, 2 Feb 2021, Julien Grall wrote:
> On 02/02/2021 18:12, Julien Grall wrote:
> > On 02/02/2021 17:47, Elliott Mitchell wrote:
> > > The handle_device() function has been returning failure upon
> > > encountering a device address which was invalid. A device tree which
> > > had such an entry
flight 158940 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken in 158901
test-amd64-amd64-libvirt-vhd
flight 158949 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken in 158915
test-arm64-arm64-xl
On Tue, Feb 02, 2021 at 04:18:44PM -0800, Stefano Stabellini wrote:
> How are you configuring and installing the kernel?
>
> make bcm2711_defconfig
> make Image.gz
> make modules_install
>
> ?
>
> The device tree is the one from the rpi-5.9.y build? How are you loading
> the kernel and device tr
Domains migrating or restoring should have viridian HVM param key in
the migration stream already and setting that twice results in Xen
returing -EEXIST on the second attempt later (during migration stream parsing)
in case the values don't match. That causes migration/restore operation
to fail at d
On 03/02/2021 04:01, Igor Druzhinin wrote:
> Domains migrating or restoring should have viridian HVM param key in
> the migration stream already and setting that twice results in Xen
> returing -EEXIST on the second attempt later (during migration stream parsing)
> in case the values don't match. T
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
> https://lore.kernel.org/linux-mm/c37de2d0-28a1-4f7d-f944-cfd7d81c3...@redhat.com/
>
> Cc: Andrew Morton
> Cc: "K.
On 02.02.21 19:37, Manuel Bouyer wrote:
Hello,
on NetBSD I'm tracking down an issue where xenstored never closes its
file descriptor to /var/run/xenstored/socket and instead loops at 100%
CPU on these descriptors.
xenstored loops because poll(2) returns a POLLIN event for these
descriptors but t
flight 158959 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158959/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3f90ac3ec03512e2374cd2968c047a7e856a8965
baseline version:
ovmf 3b468095cd3dfcd1aa4ae
flight 158973 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158973/
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
Hi again,
On Tue, 2021-02-02 at 15:23 +, Julien Grall wrote:
> (Adding Andrew, Jan, Juergen for visibility)
>
Thanks! :-)
> On 02/02/2021 15:03, Dario Faggioli wrote:
> > On Tue, 2021-02-02 at 07:59 +, Julien Grall wrote:
> > > The placement in enter_hypervisor_from_guest() doesn't matt
On 3.2.2021 2.18, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Jukka Kaartinen wrote:
Hi Roman,
Good catch.
GPU works now and I can start X! Thanks! I was also able to create domU
that runs Raspian OS.
This is very interesting that you were able to achieve that - congrats!
Now, sorry
> From: Jan Beulich
> Sent: Friday, January 29, 2021 7:45 PM
>
> There are three noteworthy drawbacks:
> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>now have to emulate certain instructions for ring 0.
> 2) On VMX there's no intercept for SMSW, so the emulation isn'
On Wed, Feb 03, 2021 at 07:18:51AM +0100, Jürgen Groß wrote:
> On 02.02.21 19:37, Manuel Bouyer wrote:
> > Hello,
> > on NetBSD I'm tracking down an issue where xenstored never closes its
> > file descriptor to /var/run/xenstored/socket and instead loops at 100%
> > CPU on these descriptors.
> >
>
71 matches
Mail list logo
