On 14.12.2022 17:36, Juergen Gross wrote:
> On 14.12.22 17:25, Daniel P. Smith wrote:
>> On 12/14/22 10:31, Juergen Gross wrote:
>>> On 14.12.22 16:03, Daniel P. Smith wrote:
On 9/10/22 11:49, Juergen Gross wrote:
> Instead of being able to use normal spinlocks as recursive ones, too,
flight 175251 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175244 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175244/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
On 14-12-22, 17:01, Oleksandr Tyshchenko wrote:
> Today I had a chance to check virtio-disk on my H/W using new Xen branch
> which does include Juergen's series with commit 3a96013a3e17
> ("tools/xenstore: reduce number of watch events").
>
> Very interesting, but I didn't manage to reproduce an i
flight 175235 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175235/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175236 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175225 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175225/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175201 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175201/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-xl
flight 175226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175221 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175221/
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. 175202
test-amd64-amd64-xl-qemuu
This avoids it being a magic constant that is difficult for humans to
decode. Use BUILD_BUG_ON to check that the old and new values are
identical.
Signed-off-by: Demi Marie Obenour
---
xen/arch/x86/include/asm/processor.h | 10 +-
xen/arch/x86/mm.c| 6 ++
2 file
No functional change intended.
Signed-off-by: Demi Marie Obenour
---
Changes since v2:
- Keep MTRR_NUM_TYPES and adjust commit message accordingly
---
xen/arch/x86/hvm/mtrr.c | 18 +-
xen/arch/x86/include/asm/mtrr.h | 2 --
xen/arch/x86/mm/shadow/multi.c | 2 +-
3 fil
This is purely for testing, to see if it works around a bug in i915. It
is not intended to be merged.
NOT-signed-off-by: DO NOT MERGE
---
xen/arch/x86/include/asm/page.h | 4 ++--
xen/arch/x86/include/asm/processor.h | 13 +
xen/arch/x86/mm.c| 2 --
3 files
It may be desirable to change Xen's PAT for various reasons. This
requires changes to several _PAGE_* macros as well. Add static
assertions to check that XEN_MSR_PAT is consistent with the _PAGE_*
macros, and that _PAGE_WB is 0 as required by Linux.
Signed-off-by: Demi Marie Obenour
---
xen/ar
Setting cacheability flags that are not ones specified by Xen is a bug
in the guest. By default, inject #GP into any guest that does this.
allow_invalid_cacheability can be used on the Xen command line to
disable this check.
Signed-off-by: Demi Marie Obenour
---
xen/arch/x86/mm.c | 25 +
This allows eliminating of the former, with the exception of
MTRR_NUM_TYPES. MTRR_NUM_TYPES is kept, as due to a quirk of the x86
architecture X86_MT_UCM (7) is not valid in an MTRR.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
Changes since v2:
- Improve commit message
-
This allows eliminating the former. No functional change intended.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
xen/arch/x86/include/asm/hvm/vmx/vmx.h | 9 -
xen/arch/x86/mm/hap/nested_ept.c | 4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --
This allows eliminating the former.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
Reviewed-by: Jan Beulich
---
Changes since v2: Style adjustments
---
xen/arch/x86/hvm/hvm.c | 12
xen/arch/x86/hvm/mtrr.c | 52 -
xen/arch
flight 175219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
These are not currently used, so there is no functional change. Future
patches will use these constants.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
Changes since v2:
- Avoid using _AC where not required.
- Define reserved memory types inline
---
xen/arch/x86/include/asm
This makes the code much easier to understand, and avoids problems if
Xen's PAT ever changes in the future.
Signed-off-by: Demi Marie Obenour
Reviewed-by: Jan Beulich
---
xen/common/efi/boot.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/common/efi/boot.c
This makes the code much easier to understand. No functional change
intended. As per Andrew Cooper, the existing logic is questionable, but
this does not make it any worse.
Signed-off-by: Demi Marie Obenour
Acked-by: Jan Beulich
---
xen/arch/x86/mm/p2m-pt.c | 6 +++---
1 file changed, 3 inser
While working on Qubes OS Marek found out that there were some PAT hacks
in the Linux i195 driver. I decided to make Xen use Linux’s PAT to see
if it solved the graphics glitches that were observed; it did. This
required a substantial amount of preliminary work that is useful even
without using L
get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
the face of future PAT changes. Use the proper _PAGE_* constants
instead. Also, treat the two unused cases as if they are cacheable, as
future changes may make them cacheable.
Signed-off-by: Demi Marie Obenour
---
xen/arch/
Hi Vipul,
For QEMU you actually need to follow the Yocto build process to update
the QEMU binary. That is because QEMU is a userspace application with
lots of library dependencies so we cannot just do "make" with a
cross-compiler like in the case of Xen.
So you need to make changes to QEMU and th
On 12/14/22 1:01 PM, Krister Johansen wrote:
On Tue, Dec 13, 2022 at 04:25:32PM -0500, Boris Ostrovsky wrote:
On 12/12/22 5:09 PM, Krister Johansen wrote:
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86/inc
flight 175214 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175214/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175215 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175197 linux-5.4 real [real]
flight 175213 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175197/
http://logs.test-lab.xenproject.org/osstest/logs/175213/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-dom0pvh-xl-intel
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbit
flight 175210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175210/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175202 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175202/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d103840cfb559c28831c2635b916d60118f671cc
baseline version:
ovmf 804e8c656643642894a26
On Wed, Dec 14, 2022 at 09:17:24AM +0100, Jan Beulich wrote:
> On 13.12.2022 19:58, Krister Johansen wrote:
> > On Tue, Dec 13, 2022 at 08:23:29AM +0100, Jan Beulich wrote:
> >> On 12.12.2022 23:05, Krister Johansen wrote:
> >>> On Mon, Dec 12, 2022 at 05:46:29PM +0100, Jan Beulich wrote:
> On
On Tue, Dec 13, 2022 at 04:25:32PM -0500, Boris Ostrovsky wrote:
>
> On 12/12/22 5:09 PM, Krister Johansen wrote:
> > On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
> > > On 12/12/22 11:05 AM, Krister Johansen wrote:
> > > > diff --git a/arch/x86/include/asm/xen/cpuid.h
> > > >
flight 175205 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
On 14.12.22 17:25, Daniel P. Smith wrote:
On 12/14/22 10:31, Juergen Gross wrote:
On 14.12.22 16:03, Daniel P. Smith wrote:
On 9/10/22 11:49, Juergen Gross wrote:
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will mak
On 12/14/22 10:31, Juergen Gross wrote:
On 14.12.22 16:03, Daniel P. Smith wrote:
On 9/10/22 11:49, Juergen Gross wrote:
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will make the spinlock structure smaller in product
flight 175189 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175189/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatch 8 xen-boot fail REGR. vs. 175144
test-xtf-amd64-amd
On 14.12.22 16:03, Daniel P. Smith wrote:
On 9/10/22 11:49, Juergen Gross wrote:
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will make the spinlock structure smaller in production builds and
add type-safety.
Just a
On 07.12.22 01:21, Viresh Kumar wrote:
+list
On 06-12-22, 13:40, Oleksandr Tyshchenko wrote:
On Tue, Dec 6, 2022 at 1:15 PM Viresh Kumar wrote:
Hi Oleksandr,
Hello Viresh
I found that my rust counterpart [1] of virtio-disk repository broke
with this commit:
commit 3a96013a3e17 ("tools/xen
> On 14 Dec 2022, at 13:08, Michal Orzel wrote:
>
> At the moment, for dom0less domUs, we do not have a way to specify
> per domain grant table related limits (unlike when using xl), namely
> max version, max number of grant frames, max number of maptrack frames.
> This means that such domains
On 9/10/22 11:49, Juergen Gross wrote:
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will make the spinlock structure smaller in production builds and
add type-safety.
Just a little yak shaving, IMHO a spinlock is nor
On 07.12.22 05:59, Viresh Kumar wrote:
Hello Viresh
First of all, sorry for the late response.
The second, thank you for the investigation.
On 07-12-22, 05:51, Viresh Kumar wrote:
I am not sure how to get this working, as there is no finalizing event
for the directory. Maybe our design is
flight 175191 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175191/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175162
test-armhf-armhf-libvirt-qcow2 15 saveres
Hi Julien,
On 12/12/2022 10:55, Julien Grall wrote:
>
>
> From: Julien Grall
>
> The sequence for flushing the TLBs is 4 instruction long and often
> requires an explanation how it works.
>
> So create an helper and use it in the boot code (switch_ttbr() is left
Here and in title: s/an helper
flight 175199 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175199/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
Hi,
On 13/12/2022 23:05, Julien Grall wrote: > On 13/12/2022 22:22, Demi
Marie Obenour wrote:
On Tue, Dec 13, 2022 at 08:55:28PM +, Julien Grall wrote:
On 13/12/2022 19:48, Smith, Jackson wrote:
Hi Xen Developers,
Hi Jackson,
Thanks for sharing the prototype with the community. Some
q
At the moment, for dom0less domUs, we do not have a way to specify
per domain grant table related limits (unlike when using xl), namely
max version, max number of grant frames, max number of maptrack frames.
This means that such domains always use the values specified by the Xen
command line parame
flight 175188 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-xl
Dear community members,
I'm pleased to announce that Xen 4.17.0 is released.
Please find the tarball and its signature at:
https://xenproject.org/downloads/xen-project-archives/xen-project-4-17-series/xen-project-4-17-0/
You can also check out the tag in xen.git:
git://xenbits.xen.org/xen.git
On Wed, Dec 14, 2022 at 11:51:31AM +0100, Jan Beulich wrote:
> On 11.12.2022 03:10, Marek Marczykowski-Górecki wrote:
> > --- a/xen/drivers/char/xhci-dbc.c
> > +++ b/xen/drivers/char/xhci-dbc.c
> > @@ -286,39 +286,87 @@ static void *dbc_sys_map_xhc(uint64_t phys, size_t
> > size)
> > return f
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> This allows eliminating most of the former. No functional change
> intended.
"most" would be nice to accompany by what has to stay, and for what reason.
Is this solely about MTRR_NUM_TYPES or more?
> --- a/xen/arch/x86/include/asm/mtrr.h
> +++ b/x
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> This allows eliminating the former.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Demi Marie Obenour
Reviewed-by: Jan Beulich
with a couple of small remarks (some asking for minor adjustments):
> @@ -72,8 +72,8 @@ static uint8_t __read_mostl
On 14.12.22 12:29, Jan Beulich wrote:
On 14.12.2022 12:10, Juergen Gross wrote:
On 14.12.22 11:39, Jan Beulich wrote:
On 10.09.2022 17:49, Juergen Gross wrote:
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -397,7 +397,7 @@ int p2m_pod_empty_cache(struct domain *d)
Hi Stewart,
> On 13 Dec 2022, at 6:18 pm, Stewart Hildebrand
> wrote:
>
> When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we observe the
> following build error:
>
> drivers/passthrough/arm/smmu-v3.c:1408:20: error: unused function
> 'arm_smmu_disable_pasid' [-Werror,-Wunused-function]
On 14.12.2022 12:10, Juergen Gross wrote:
> On 14.12.22 11:39, Jan Beulich wrote:
>> On 10.09.2022 17:49, Juergen Gross wrote:
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -397,7 +397,7 @@ int p2m_pod_empty_cache(struct domain *d)
>>>
>>> /* After this bar
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/include/asm/x86-defns.h
> +++ b/xen/arch/x86/include/asm/x86-defns.h
> @@ -153,4 +153,17 @@
> (1u << X86_EXC_AC) | (1u << X86_EXC_CP) | \
> (1u << X86_EXC_VC) | (1u << X86_EXC_SX))
>
> +/* Memory
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> This makes the code much easier to understand. No functional change
> intended. As per Andrew Cooper, the existing logic is incorrect, but
> this does not make it any worse.
>
> Signed-off-by: Demi Marie Obenour
Acked-by: Jan Beulich
I'm incli
On 14.12.22 11:39, Jan Beulich wrote:
On 10.09.2022 17:49, Juergen Gross wrote:
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -397,7 +397,7 @@ int p2m_pod_empty_cache(struct domain *d)
/* After this barrier no new PoD activities can happen. */
BUG_ON(!d->is_d
On 13.12.2022 17:00, Juergen Gross wrote:
> This is a first run of post-XSA patches which piled up during the
> development phase of all the recent Xenstore related XSA patches.
>
> At least the first 5 patches are completely independent from each
> other. After those the dependencies are starting
On 14.12.2022 10:34, Jan Beulich wrote:
> On 14.12.2022 00:03, Demi Marie Obenour wrote:
>> This was missed in the initial patchset.
>>
>> Signed-off-by: Demi Marie Obenour
>
> I'm sorry, but no: In a v2 submission you should address prior comments.
> On v1 I did offer to extend the description w
On 11.12.2022 03:10, Marek Marczykowski-Górecki wrote:
> --- a/xen/drivers/char/xhci-dbc.c
> +++ b/xen/drivers/char/xhci-dbc.c
> @@ -286,39 +286,87 @@ static void *dbc_sys_map_xhc(uint64_t phys, size_t size)
> return fix_to_virt(FIX_XHCI_END);
> }
>
> +static void xhci_bios_handoff(struct d
On 11.12.2022 03:10, Marek Marczykowski-Górecki wrote:
> AMD's XHCI has BAR0 of 1M (compared to 64K on Intel). Map it as a whole
> (reserving more space in the fixmap). Make fixmap slot conditional on
> CONFIG_XHCI.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
> --- a
On Wed, Dec 14, 2022 at 02:04:56PM +0530, Viresh Kumar wrote:
> On 14-12-22, 09:21, Jan Beulich wrote:
> > On 14.12.2022 06:19, Viresh Kumar wrote:
> > > This patchset adds toolstack support for I2C, GPIO and generic virtio
> > > devices.
> > > This is inspired from the work done by Oleksandr for
On 10.09.2022 17:49, Juergen Gross wrote:
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -397,7 +397,7 @@ int p2m_pod_empty_cache(struct domain *d)
>
> /* After this barrier no new PoD activities can happen. */
> BUG_ON(!d->is_dying);
> -spin_barrier(&p2m->
On 14.12.22 11:32, Jan Beulich wrote:
On 14.12.2022 11:21, Jan Beulich wrote:
On 10.09.2022 17:49, Juergen Gross wrote:
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are use r
On 14.12.2022 11:21, Jan Beulich wrote:
> On 10.09.2022 17:49, Juergen Gross wrote:
>> In order to prepare a type-safe recursive spinlock structure, add
>> explicitly non-recursive locking functions to be used for non-recursive
>> locking of spinlocks, which are use recursively, too.
>
> While I c
On 14.12.22 11:21, Jan Beulich wrote:
On 10.09.2022 17:49, Juergen Gross wrote:
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are use recursively, too.
While I can see that s
On 10.09.2022 17:49, Juergen Gross wrote:
> In order to prepare a type-safe recursive spinlock structure, add
> explicitly non-recursive locking functions to be used for non-recursive
> locking of spinlocks, which are use recursively, too.
While I can see that something needs doing, a function nam
On 14.12.22 10:54, Jan Beulich wrote:
On 13.12.2022 17:00, Juergen Gross wrote:
Today talloc_free() is not guaranteed to preserve errno, especially in
case a custom destructor is being used.
Change that by renaming talloc_free() to _talloc_free() in talloc.c and
adding a wrapper to talloc.c.
On 13.12.2022 17:00, Juergen Gross wrote:
> Today talloc_free() is not guaranteed to preserve errno, especially in
> case a custom destructor is being used.
>
> Change that by renaming talloc_free() to _talloc_free() in talloc.c and
> adding a wrapper to talloc.c.
This looks to be stale ...
> Th
On 13.12.2022 17:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/include/asm/perfc_defn.h
> +++ b/xen/arch/x86/include/asm/perfc_defn.h
> @@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32)
>
> #ifdef CONFIG_HVM
>
> -#define VMX_PERF_EXIT_REASON_SIZE 65
> +#define VMX_PER
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> Also force the unused entries to UC and add a comment.
>
> Signed-off-by: Demi Marie Obenour
See my v1 comment as to what further needs saying / justifying.
Jan
On 13.12.2022 23:26, Demi Marie Obenour wrote:
> This makes the code much easier to understand, and avoids problems if
> Xen's PAT ever changes in the future.
>
> Reviewed-by: Jan Beulich
> Signed-off-by: Demi Marie Obenour
Nit (quoting docs/process/sending-patches.doc):
In general tags are ad
On 14.12.2022 00:03, Demi Marie Obenour wrote:
> This was missed in the initial patchset.
>
> Signed-off-by: Demi Marie Obenour
I'm sorry, but no: In a v2 submission you should address prior comments.
On v1 I did offer to extend the description while committing, but you
should not take this as a
flight 175186 qemu-mainline real [real]
flight 175194 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175186/
http://logs.test-lab.xenproject.org/osstest/logs/175194/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 13.12.2022 20:50, Smith, Jackson wrote:
> This commit introduces a new vmf_op hypercall. If desired, could be merged
> into an exisiting hypercall.
>
> Also, introduce a VMF Kconfig option and xen/vmf.h, defining the arch specific
> functions that must be implmented to support vmf.
Neither her
On 14.12.2022 10:00, Lin Liu （刘林） wrote:
> Our internal regression testing detected a panic recently.
> Could you please help to verify whether it is introduced by these patch
> series?
Please see
https://lists.xen.org/archives/html/xen-devel/2022-12/msg00879.html
and
https://lists.xen.org/archiv
On 14.12.22 11:09, Jan Beulich wrote:
Hello all
On 14.12.2022 09:34, Viresh Kumar wrote:
On 14-12-22, 09:21, Jan Beulich wrote:
On 14.12.2022 06:19, Viresh Kumar wrote:
This patchset adds toolstack support for I2C, GPIO and generic virtio devices.
This is inspired from the work done by Ole
On 13.12.2022 22:44, Julien Grall wrote:
> On 19/10/2022 08:40, Jan Beulich wrote:
>> In preparation of the introduction of new vCPU operations allowing to
>> register the respective areas (one of the two is x86-specific) by
>> guest-physical address, add the necessary domain cleanup hooks.
>>
>> S
Hi Demi,
On 14/12/2022 01:38, Demi Marie Obenour wrote:
On Tue, Dec 13, 2022 at 11:07:55PM +, Julien Grall wrote:
Hi Demi,
On 13/12/2022 22:17, Demi Marie Obenour wrote:
On Tue, Dec 13, 2022 at 09:15:49PM +, Julien Grall wrote:
[snip]
+
+/*
+ * Generate the entry for this
On 14.12.2022 09:34, Viresh Kumar wrote:
> On 14-12-22, 09:21, Jan Beulich wrote:
>> On 14.12.2022 06:19, Viresh Kumar wrote:
>>> This patchset adds toolstack support for I2C, GPIO and generic virtio
>>> devices.
>>> This is inspired from the work done by Oleksandr for the Disk device.
>>>
>>> Thi
Hi Wei,
Our internal regression testing detected a panic recently.
Could you please help to verify whether it is introduced by these patch series?
Thanks for your help!
Best Regards!
Lin
[2022-12-13 00:29:25 UTC] (XEN) [0038170b9b04] System RAM: 49139MB
(50318428kB)
[2022-12-13 00:29:25 UTC]
On 14-12-22, 09:21, Jan Beulich wrote:
> On 14.12.2022 06:19, Viresh Kumar wrote:
> > This patchset adds toolstack support for I2C, GPIO and generic virtio
> > devices.
> > This is inspired from the work done by Oleksandr for the Disk device.
> >
> > This is developed as part of Linaro's Project
On 14.12.2022 06:19, Viresh Kumar wrote:
> This patchset adds toolstack support for I2C, GPIO and generic virtio devices.
> This is inspired from the work done by Oleksandr for the Disk device.
>
> This is developed as part of Linaro's Project Stratos, where we are working
> towards Hypervisor agn
On 13.12.2022 19:58, Krister Johansen wrote:
> On Tue, Dec 13, 2022 at 08:23:29AM +0100, Jan Beulich wrote:
>> On 12.12.2022 23:05, Krister Johansen wrote:
>>> On Mon, Dec 12, 2022 at 05:46:29PM +0100, Jan Beulich wrote:
On 12.12.2022 17:05, Krister Johansen wrote:
> Both the Intel SDM[4]
87 matches
Mail list logo
