Stefano Stabellini wrote on Wed, May 20, 2020:
> From: Stefano Stabellini
>
> Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> max allowed by the protocol.
>
> We can't assume that all backends will support order 9. The xenstore
> property max-ring-page-order specifies
For the last couple years we have received numerous reports from users of
monitor vm_events of spurious guest crashes when using events. In particular,
it has observed that the problem occurs when vm_events are being disabled. The
nature of the guest crash varied widely and has only occured occasio
Extend the monitor_op domctl to include option that enables
controlling what values certain registers are permitted to hold
by a monitor subscriber.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c | 25 -
xen/arch/x86/monitor.c | 10 +-
xen/i
Instead of having to repeatedly try to disable vm_events, request a specific
vm_event to be sent when the domain is safe to continue with shutting down
the vm_event interface.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c| 38 ++-
xen/arch/x86/
Perform sanity checking when shutting vm_event down to determine whether
it is safe to do so. Error out with -EAGAIN in case pending operations
have been found for the domain.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/vm_event.c| 23 +++
xen/common/vm_event.c
flight 150279 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 150267
Tests which did no
On Wed, May 20, 2020 at 7:45 AM Jan Beulich wrote:
>
> On 15.05.2020 18:53, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -563,15 +563,41 @@ void hvm_do_resume(struct vcpu *v)
> > v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
>
On Wed, May 20, 2020 at 7:48 AM Jan Beulich wrote:
>
> On 20.05.2020 15:42, Tamas K Lengyel wrote:
> > On Wed, May 20, 2020 at 7:36 AM Jan Beulich wrote:
> >>
> >> On 15.05.2020 18:53, Tamas K Lengyel wrote:
> >>> Extend the monitor_op domctl to include option that enables
> >>> controlling what
On Wed, 20 May 2020, Roman Shaposhnik wrote:
> On Wed, May 20, 2020 at 4:45 PM Stefano Stabellini
> wrote:
> >
> > Hi all,
> >
> > This series is a collection of fixes to get Linux running on the RPi4 as
> > dom0.
> >
> > Conceptually there are only two significant changes:
> >
> > - make sure not
On Wed, May 20, 2020 at 4:45 PM Stefano Stabellini
wrote:
>
> Hi all,
>
> This series is a collection of fixes to get Linux running on the RPi4 as
> dom0.
>
> Conceptually there are only two significant changes:
>
> - make sure not to call virt_to_page on vmalloc virt addresses (patch
> #1)
> -
From: Stefano Stabellini
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all the following pages, in
case of multipage handling.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --gi
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --gi
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0.
Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and dma_to_phys to translate phys to/from dma
addresses (all
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 958e
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ef58f05
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 5 +
1 file changed, 1 insertion(+), 4 deletions
From: Stefano Stabellini
Call dma_to_phys in is_xen_swiotlb_buffer.
Call phys_to_dma in xen_phys_to_bus.
Call dma_to_phys in xen_bus_to_phys.
Everything is taken care of by these changes except for
xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a
few explicit phys_to_dma/dm
From: Boris Ostrovsky
Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addresses.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 5 -
1 file cha
From: Stefano Stabellini
Add phys_to_dma/dma_to_phys calls to
xen_dma_sync_for_cpu, xen_dma_sync_for_device, and
xen_arch_need_swiotlb.
In xen_arch_need_swiotlb, take the opportunity to switch to the simpler
pfn_valid check we use everywhere else.
dma_cache_maint is fixed by the next patch.
Si
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index
On 18/05/2020 14:19, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from a BIOS
> not performing the proper
On Mon, 18 May 2020, Julien Grall wrote:
> From: Julien Grall
>
> Hi all,
>
> At the moment, a user who wants to boot Xen on the Raspberry Pi 4 can
> only use the first GB of memory.
>
> This is because several devices cannot DMA above 1GB but Xen doesn't
> necessarily allocate memory for Dom0
On Mon, 18 May 2020, Volodymyr Babchuk wrote:
> Hi Julien,
>
> On Mon, 2020-05-18 at 12:30 +0100, Julien Grall wrote:
> > From: Julien Grall
> >
> > At the moment, Xen is assuming that all the devices are at least 32-bit
> > DMA capable. However, some SoC have devices that may be able to access
On 15/05/2020 14:58, Roger Pau Monne wrote:
> Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
> BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
> Dispatched Before an Interrupt of The Same Priority Completes".
HSM175 et al, so presumably a HSD, and HSE as well.
On 20/05/2020 13:52, Jan Beulich wrote:
> For lbr_tsx_fixup_check() simply name a few more specific errata numbers.
>
> For bdf93_fixup_check(), however, more models are affected. Oddly enough
> despite being the same model and stepping, the erratum is listed for Xeon
> E3 but not its Core counterp
flight 150280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150280/
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 1
On Wed, 20 May 2020, Dominique Martinet wrote:
> Stefano Stabellini wrote on Wed, May 20, 2020:
> > From: Stefano Stabellini
> >
> > Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> > max allowed by the protocol.
> >
> > We can't assume that all backends will support or
flight 150278 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150278/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3733188a2162abf72dd08c0cedd1119b5cfe6c4
baseline version:
ovmf 7b6327ff03bb4436261ff
flight 150273 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150273/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 150172
Tests which did not succeed, b
From: Stefano Stabellini
Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
max allowed by the protocol.
We can't assume that all backends will support order 9. The xenstore
property max-ring-page-order specifies the max order supported by the
backend. We'll use max-ring-pa
On 18/05/2020 16:47, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 18.05.2020 17:45, Roger Pau Monné wrote:
>> On Mon, May 18, 2020 at 05:05:12PM +0200, Jan Beulich wrote:
>>
flight 150271 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150271/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 7 xen-boot fail in 150260 pass in 150271
test-amd64-amd64-xl-rtds 15
On Wed, 20 May 2020, Jürgen Groß wrote:
> On 20.05.20 08:00, Jürgen Groß wrote:
> > On 19.05.20 23:21, Stefano Stabellini wrote:
> > > Hi Juergen, Boris,
> > >
> > > I am trying to increase the size of the rings used for Xen 9pfs
> > > connections for performance reasons and also to reduce the lik
Anthony PERARD writes ("[XEN PATCH] tools/xenstore: mark variable in header as
extern"):
> This patch fix "multiple definition of `xprintf'" (or xgt_handle)
> build error with GCC 10.1.0.
Reviewed-by: Ian Jackson
On Wed, May 20, 2020 at 03:12:25PM +0200, Jan Beulich wrote:
> On 20.05.2020 13:43, Roger Pau Monné wrote:
> > On Wed, May 20, 2020 at 12:57:27PM +0200, Jan Beulich wrote:
> >> On 20.05.2020 12:28, Roger Pau Monné wrote:
> >>> On Wed, May 20, 2020 at 12:17:15PM +0200, Jan Beulich wrote:
> On 2
On 20/05/2020 17:39, Anthony PERARD wrote:
> This patch fix "multiple definition of `xprintf'" (or xgt_handle)
> build error with GCC 10.1.0.
>
> These are the error reported:
> gcc xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
> /usr/bin/ld: utils.o:./utils.h:27: multiple defini
On 20/05/2020 15:59, Elliot Killick wrote:
> On 2020-05-20 12:31, Andrew Cooper wrote:
>> On 20/05/2020 12:46, Elliot Killick wrote:
>>> processor : 0
>>> vendor_id : GenuineIntel
>>> cpu family : 6
>>> model : 60
>>> model name : Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
>>> step
flight 150267 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150267/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 150227
test-armhf-armhf-xl-rtds
On 20/05/2020 16:56, Jan Beulich wrote:
> On 20.05.2020 16:07, Andrew Cooper wrote:
>> On 20/05/2020 13:52, Jan Beulich wrote:
>>> @@ -2895,15 +2897,26 @@ static void __init lbr_tsx_fixup_check(v
>>> static void __init bdf93_fixup_check(void)
>> Seeing as this is no longer just BDF93, how about le
This patch fix "multiple definition of `xprintf'" (or xgt_handle)
build error with GCC 10.1.0.
These are the error reported:
gcc xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
/usr/bin/ld: utils.o:./utils.h:27: multiple definition of `xprintf';
xs_tdb_dump.o:./utils.h:27: first
On Wed, May 20, 2020 at 03:49:59PM +0100, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of allocated
> memory"):
> > The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF
> > ioctl() parameters is calculated wrong, which results in too much
> >
On 20.05.2020 16:07, Andrew Cooper wrote:
> On 20/05/2020 13:52, Jan Beulich wrote:
>> @@ -2895,15 +2897,26 @@ static void __init lbr_tsx_fixup_check(v
>> static void __init bdf93_fixup_check(void)
>
> Seeing as this is no longer just BDF93, how about ler_tsx_fixup_check() ?
I did consider renam
On 20/05/2020 08:48, Jan Beulich wrote:
> On 19.05.2020 20:00, Andrew Cooper wrote:
>> On 19/05/2020 17:09, Jan Beulich wrote:
>>> In any event there would be 12 bits to reclaim from the up
>>> pointer - it being a physical address, there'll not be more
>>> than 52 significant bits.
>> Right, but f
On Wed, May 20, 2020 at 7:45 AM Jan Beulich wrote:
>
> On 15.05.2020 18:53, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -563,15 +563,41 @@ void hvm_do_resume(struct vcpu *v)
> > v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
>
On Wed, May 20, 2020 at 10:56:26AM +0200, Jan Beulich wrote:
> On 18.05.2020 16:51, Roger Pau Monné wrote:
> > On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote:
> >> On 27.04.2020 22:11, Andrew Cooper wrote:
> >>> On 27/04/2020 16:15, Jan Beulich wrote:
> On 27.04.2020 16:35, Andrew
On 2020-05-20 12:31, Andrew Cooper wrote:
> On 20/05/2020 12:46, Elliot Killick wrote:
>> On 2020-05-20 11:27, Andrew Cooper wrote:
>>> On 20/05/2020 12:20, Elliot Killick wrote:
On 2020-05-20 11:10, Andrew Cooper wrote:
> On 20/05/2020 11:33, Elliot Killick wrote:
>> Hello,
>>
>>>
Julien Grall writes ("Re: [OSSTEST PATCH 34/38] buster: grub, arm64: extend
chainloading workaround"):
> On 19/05/2020 20:02, Ian Jackson wrote:
> > multiboot[2] isn't supported.
> >
> > Also link to the bug report.
> >
> > CC: Julien Grall
> > CC: Stefano Stabellini
> > Signed-off-by: Ian Jac
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
> On 19/05/2020 20:02, Ian Jackson wrote:
> > CC: Julien Grall
> > CC: Stefano Stabellini
> > Signed-off-by: Ian Jackson
>
> Acked-by: Julien Grall
Thanks.
> > # Debian doesn't currently know w
Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of allocated
memory"):
> The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF
> ioctl() parameters is calculated wrong, which results in too much
> memory allocated.
Added Roger to CC.
Firstly,
Reviewed-by: Ian Jacks
On 20/05/2020 15:20, Jan Beulich wrote:
> The {evex} pseudo prefix gets rejected by gas for insns not allowing
> EVEX encoding. Except there's a gas bug due to which its check gets
> bypassed for insns without operands. Let's not rely on that bug to
> remain there.
>
> Signed-off-by: Jan Beulich
flight 150276 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150276/
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 1
The {evex} pseudo prefix gets rejected by gas for insns not allowing
EVEX encoding. Except there's a gas bug due to which its check gets
bypassed for insns without operands. Let's not rely on that bug to
remain there.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools
On Wed, May 20, 2020 at 01:14:18PM +0100, Ian Jackson wrote:
> Hi. As maintainer of the Xen Project upstream CI, I do testing of
> upstream Xen builds onto Debian systems.
>
> We use grub's 20_linux_xen to do the bootloader setup. However, it is
> missing some features so we are carrying some patc
On 20/05/2020 13:52, Jan Beulich wrote:
> For lbr_tsx_fixup_check() simply name a few more specific errata numbers.
>
> For bdf93_fixup_check(), however, more models are affected. Oddly enough
> despite being the same model and stepping, the erratum is listed for Xeon
> E3 but not its Core counterp
On 20.05.2020 15:42, Tamas K Lengyel wrote:
> On Wed, May 20, 2020 at 7:36 AM Jan Beulich wrote:
>>
>> On 15.05.2020 18:53, Tamas K Lengyel wrote:
>>> Extend the monitor_op domctl to include option that enables
>>> controlling what values certain registers are permitted to hold
>>> by a monitor su
On 15.05.2020 18:53, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -563,15 +563,41 @@ void hvm_do_resume(struct vcpu *v)
> v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
> }
>
> -if ( unlikely(v->arch.vm_event) &&
> v->arch
On Wed, May 20, 2020 at 7:36 AM Jan Beulich wrote:
>
> On 15.05.2020 18:53, Tamas K Lengyel wrote:
> > Extend the monitor_op domctl to include option that enables
> > controlling what values certain registers are permitted to hold
> > by a monitor subscriber.
>
> This needs a bit more explanation,
On 15.05.2020 18:53, Tamas K Lengyel wrote:
> Extend the monitor_op domctl to include option that enables
> controlling what values certain registers are permitted to hold
> by a monitor subscriber.
This needs a bit more explanation, especially for those of us
who aren't that introspection savvy.
On 20.05.2020 13:43, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 12:57:27PM +0200, Jan Beulich wrote:
>> On 20.05.2020 12:28, Roger Pau Monné wrote:
>>> On Wed, May 20, 2020 at 12:17:15PM +0200, Jan Beulich wrote:
On 20.05.2020 11:31, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 1
For lbr_tsx_fixup_check() simply name a few more specific errata numbers.
For bdf93_fixup_check(), however, more models are affected. Oddly enough
despite being the same model and stepping, the erratum is listed for Xeon
E3 but not its Core counterpart. With this it's of course also uncertain
whet
On 20/05/2020 12:46, Elliot Killick wrote:
> On 2020-05-20 11:27, Andrew Cooper wrote:
>> On 20/05/2020 12:20, Elliot Killick wrote:
>>> On 2020-05-20 11:10, Andrew Cooper wrote:
On 20/05/2020 11:33, Elliot Killick wrote:
> Hello,
>
> Xen is crashing Windows 10 (64-bit) VMs consist
Hi. As maintainer of the Xen Project upstream CI, I do testing of
upstream Xen builds onto Debian systems.
We use grub's 20_linux_xen to do the bootloader setup. However, it is
missing some features so we are carrying some patches. Here they are
for your consideration.
Regards, Ian.
Ian Jackso
"file_is_not_sym" currently only checks for xen-syms. Extend it to
disregard xenpolicy (XSM policy files) and files ending .config (which
are built by the Xen upstream build system in some configurations and
can therefore end up in /boot).
Rename the function accordingly, to "file_is_not_xen_garb
XSM is enabled by adding "flask=enforcing" as a Xen command line
argument, and providing the policy file as a grub module.
We make entries for both with and without XSM. If XSM is not compiled
into Xen, then there are no policy files, so no change to the boot
options.
Signed-off-by: Ian Jackson
On 2020-05-20 11:27, Andrew Cooper wrote:
> On 20/05/2020 12:20, Elliot Killick wrote:
>> On 2020-05-20 11:10, Andrew Cooper wrote:
>>> On 20/05/2020 11:33, Elliot Killick wrote:
Hello,
Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
Debugger
(https://www.
On Wed, May 20, 2020 at 12:57:27PM +0200, Jan Beulich wrote:
> On 20.05.2020 12:28, Roger Pau Monné wrote:
> > On Wed, May 20, 2020 at 12:17:15PM +0200, Jan Beulich wrote:
> >> On 20.05.2020 11:31, Roger Pau Monné wrote:
> >>> On Wed, May 20, 2020 at 10:31:38AM +0200, Jan Beulich wrote:
> On 1
Hi,
On 19/05/2020 20:02, Ian Jackson wrote:
multiboot[2] isn't supported.
Also link to the bug report.
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
---
Osstest/Debian.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 20/05/2020 12:20, Elliot Killick wrote:
> On 2020-05-20 11:10, Andrew Cooper wrote:
>> On 20/05/2020 11:33, Elliot Killick wrote:
>>> Hello,
>>>
>>> Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
>>> Debugger
>>> (https://www.hex-rays.com/products/ida/support/download_freeware
flight 150266 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150266/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150244
test-amd64-amd64-xl-qemut-win7-amd64
Hi Ian,
On 19/05/2020 20:02, Ian Jackson wrote:
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6fed0b75..775
Hi,
On 19/05/2020 20:02, Ian Jackson wrote:
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On 2020-05-20 11:10, Andrew Cooper wrote:
> On 20/05/2020 11:33, Elliot Killick wrote:
>> Hello,
>>
>> Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
>> Debugger
>> (https://www.hex-rays.com/products/ida/support/download_freeware/)
>> launches the Local Windows Debugger. The cras
On 20/05/2020 11:16, Juergen Gross wrote:
Update connection record details: make flags common for sockets and
domains, and add pending incoming data.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
docs/designs/xenstore-migration.md | 63 --
1 f
On 11.05.2020 19:43, buy computer wrote:
> I've been working on a Windows 10 HVM on a Debian 10 dom0. When I was first
> trying to make the VM, I was getting IOMMU errors. I had a hard time
> figuring out what to do about this, and finally discovered that putting
> iommu=no-igfx in the grub stopped
On 20/05/2020 11:33, Elliot Killick wrote:
> Hello,
>
> Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
> Debugger
> (https://www.hex-rays.com/products/ida/support/download_freeware/)
> launches the Local Windows Debugger. The crash occurs when trying to
> launch the debugger agai
On 20.05.2020 12:28, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 12:17:15PM +0200, Jan Beulich wrote:
>> On 20.05.2020 11:31, Roger Pau Monné wrote:
>>> On Wed, May 20, 2020 at 10:31:38AM +0200, Jan Beulich wrote:
On 14.05.2020 16:05, Roger Pau Monné wrote:
> On Mon, Jul 15, 2019 at 0
> -Original Message-
> From: Xen-devel On Behalf Of Juergen
> Gross
> Sent: 20 May 2020 11:16
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall
> ; Wei Liu ; Andrew Cooper
> ; Ian Jackson
> ; George Dunlap ; Jan
> Beulich
> Subject: [PATCH]
Hello,
Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
Debugger
(https://www.hex-rays.com/products/ida/support/download_freeware/)
launches the Local Windows Debugger. The crash occurs when trying to
launch the debugger against any executable (e.g. calc.exe) right at the
time IDA
On Wed, May 20, 2020 at 12:17:15PM +0200, Jan Beulich wrote:
> On 20.05.2020 11:31, Roger Pau Monné wrote:
> > On Wed, May 20, 2020 at 10:31:38AM +0200, Jan Beulich wrote:
> >> On 14.05.2020 16:05, Roger Pau Monné wrote:
> >>> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> @@ -
On Wed, May 20, 2020 at 09:53:50AM +0200, Jan Beulich wrote:
> It is wrong for us to check frames beyond the guest specified limit
> (in the compat case another loop bound is already correct).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
flight 150274 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150274/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen e235fa2794c95365519eac714d6ea82f8e64752e
baseline version:
xen 664e
On 20.05.2020 11:31, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 10:31:38AM +0200, Jan Beulich wrote:
>> On 14.05.2020 16:05, Roger Pau Monné wrote:
>>> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
@@ -251,6 +255,10 @@ boot/mkelf32: boot/mkelf32.c
efi/mkreloc: efi/m
Update connection record details: make flags common for sockets and
domains, and add pending incoming data.
Signed-off-by: Juergen Gross
---
docs/designs/xenstore-migration.md | 63 --
1 file changed, 34 insertions(+), 29 deletions(-)
diff --git a/docs/designs/xensto
On 24.04.2020 16:09, Hongyan Xia wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -815,7 +815,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
> if ( !opt_xpti_hwdom && !opt_xpti_domu )
> return 0;
>
> -rpt = alloc_xen_pagetable();
> +rpt = alloc
On 24.04.2020 16:09, Hongyan Xia wrote:
> From: Wei Liu
>
> No functional change.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Acked-by: Jan Beulich
On 24.04.2020 16:08, Hongyan Xia wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -379,13 +379,13 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
> {
> unsigned long i, va, smap, emap;
> unsigned int n;
> -l2_pgentry_t *l2_ro_mpt = NULL;
>
On 24.04.2020 16:08, Hongyan Xia wrote:
> @@ -493,22 +494,28 @@ void __init paging_init(void)
> if ( !(l4e_get_flags(idle_pg_table[l4_table_offset(va)]) &
>_PAGE_PRESENT) )
> {
> -l3_pgentry_t *pl3t = alloc_xen_pagetable();
> +l3_pgentry_t *
On 24.04.2020 16:08, Hongyan Xia wrote:
> From: Wei Liu
>
> Introduce pl2e so that we can use l2_ro_mpt to point to the page table
> itself.
>
> No functional change.
>
> Signed-off-by: Wei Liu
In principle I'm fine with the change, as a preparatory one for
the next patch. The description, ho
On Wed, May 20, 2020 at 10:31:38AM +0200, Jan Beulich wrote:
> On 14.05.2020 16:05, Roger Pau Monné wrote:
> > On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> >> @@ -251,6 +255,10 @@ boot/mkelf32: boot/mkelf32.c
> >> efi/mkreloc: efi/mkreloc.c
> >>$(HOSTCC) $(HOSTCFLAGS) -g -o
On 24.04.2020 16:08, Hongyan Xia wrote:
> @@ -4998,31 +5005,40 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
> if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
> {
> bool locking = system_state > SYS_STATE_boot;
> -l2_pgentry_t *l2t = alloc_xen_pagetable();
> +
From: Oleksandr Andrushchenko
Hello all,
this series extends the existing displif protocol with new
request and adds additional parameter to the exiting one.
It also provides support for the new parameter in libgnttab
via ioctl. The relevant changes in the backend can be found at [1]
and the fro
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
make the version an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
From: Oleksandr Andrushchenko
Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
dma-buf is backed by a scatter-gather table and has offset parameter
which tells where the actual data starts. Relevant ioctls are extended
to support that offset:
- when dma-buf is created (export
On 18.05.2020 16:51, Roger Pau Monné wrote:
> On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote:
>> On 27.04.2020 22:11, Andrew Cooper wrote:
>>> On 27/04/2020 16:15, Jan Beulich wrote:
On 27.04.2020 16:35, Andrew Cooper wrote:
> On 27/04/2020 09:03, Jan Beulich wrote:
>> ---
On 20.05.20 08:00, Jürgen Groß wrote:
On 19.05.20 23:21, Stefano Stabellini wrote:
Hi Juergen, Boris,
I am trying to increase the size of the rings used for Xen 9pfs
connections for performance reasons and also to reduce the likehood of
the backend having to wait on the frontend to free up spac
The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF
ioctl() parameters is calculated wrong, which results in too much
memory allocated.
Signed-off-by: Juergen Gross
---
tools/libs/gnttab/freebsd.c | 2 +-
tools/libs/gnttab/linux.c | 8 +++-
2 files changed, 4 insertions(+),
On 14.05.2020 16:05, Roger Pau Monné wrote:
> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
>> @@ -251,6 +255,10 @@ boot/mkelf32: boot/mkelf32.c
>> efi/mkreloc: efi/mkreloc.c
>> $(HOSTCC) $(HOSTCFLAGS) -g -o $@ $<
>>
>> +nocov-y += hweight.o
>> +noubsan-y += hweight.o
>> +h
There's no need to invoke get_page_from_gfn(), and there's also no need
to update the passed in frames[]. Invoke get_page_and_type() directly.
Also make the function's frames[] parameter const, change its return
type to int, and drop the bogus casts from two of its invocations.
Finally a little b
It is wrong for us to check frames beyond the guest specified limit
(in the compat case another loop bound is already correct).
Signed-off-by: Jan Beulich
---
v3: Move nr_gdt_frames range check earlier. Avoid |= where not really
needed.
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
1 - 100 of 105 matches
Mail list logo
