flight 150141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150141/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9378310dd877b99be1da398f39e82e0501aca372
baseline version:
ovmf c8543b8d830d22882dab4
On 11.05.20 23:41, Stefano Stabellini wrote:
On Mon, 11 May 2020, Juergen Gross wrote:
backend_connect() can fail, so switch the device to connected only if
no error occurred.
Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
Hi!
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 the errors.
Unfortunately, without the gra
flight 150139 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 150109
Tests which did n
Two patches to fix building with a cf-protection toolchain. The first
handles the case where the compiler fails to run with "error:
‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible".
The second fixes a runtime error that prevented Xen booting in legacy
mode.
I still haven't figured o
reloc.S and cmdline.S as arrays of executable bytes for inclusion in
head.S generated from compiled object files. Object files generated by
an -fcf-protection toolchain include a .note.gnu.property section. The
way reloc.S and cmdline.S are generated, the bytes of .note.gnu.property
become the st
Ubuntu gcc-9 enables -fcf-protection by default, which conflicts with
-mindirect-branch=extern and prevents building the hypervisor with
CONFIG_INDIRECT_THUNK:
xmalloc.h:81:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not
compatible
Detect this incompatible combination, and add -fcf-pro
On Thu, 30 Apr 2020, Julien Grall wrote:
> On 30/04/2020 18:00, Stefano Stabellini wrote:
> > On Thu, 30 Apr 2020, Julien Grall wrote:
> > > > > > +pg = maddr_to_page(start);
> > > > > > +node = phys_to_nid(start);
> > > > > > +zone = page_to_zone(pg);
> > > > > > +page_list_del(pg,
flight 150136 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-build fail in 150130 REGR. vs. 150104
Tests which are faili
On 07/05/2020 15:54, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/acpi/wakeup_prot.S
>> +++ b/xen/arch/x86/acpi/wakeup_prot.S
>> @@ -1,3 +1,8 @@
>> +#include
> Why is this needed? Afaics assembly files, just like C ones, get
> xen/config.h included from the
flight 150135 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150135/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150128 pass in
150135
test-armhf-armhf-xl-arndal
On Sat, 9 May 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 09/05/2020 01:07, Stefano Stabellini wrote:
> > On Fri, 1 May 2020, Julien Grall wrote:
> > > On 01/05/2020 02:26, Stefano Stabellini wrote:
> > > > On Wed, 15 Apr 2020, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
> > > > > On 1
On Mon, 11 May 2020, Andrew Cooper wrote:
> On 11/05/2020 10:34, Julien Grall wrote:
> > Hi Volodymyr,
> >
> > On 06/05/2020 02:44, Volodymyr Babchuk wrote:
> >> Normal World can share buffer with OP-TEE for two reasons:
> >> 1. Some client application wants to exchange data with TA
> >> 2. OP-TEE
On 07/05/2020 17:15, Jan Beulich wrote:
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -194,6 +194,15 @@ restore_all_guest:
movq 8(%rsp),%rcx# RIP
jairet_exit_to_guest
+/* Clear the supervisor sh
On Mon, 11 May 2020, Juergen Gross wrote:
> backend_connect() can fail, so switch the device to connected only if
> no error occurred.
>
> Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
On 07/05/2020 14:35, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -778,6 +778,28 @@ static bool exception_fixup(struct cpu_user_regs *regs,
>> bool print)
>> vec_name(regs->entry_vector), regs->erro
Ping?
-Jason
On Tue, Apr 28, 2020 at 12:05 AM Jason Andryuk wrote:
>
> Hi,
>
> In coordination with Marek, I'm making a submission of his patches for Linux
> stubdomain device-model support. I made a few of my own additions, but Marek
> did the heavy lifting. Thank you, Marek.
>
> Below is mos
>
> On May 7, 2020, at 18:50, George Dunlap wrote:
> We’re still ironing out all the details, but it’s absolutely confirmed that
> XenSummit 2020 will be held virtually in June.
>
> In addition, the new version of the Design Sessions website is now live:
>
> https://design-sessions.xenproje
On May 7, 2020, at 18:50, George Dunlap wrote:
>
> We’re still ironing out all the details, but it’s absolutely confirmed that
> XenSummit 2020 will be held virtually in June.
>
> In addition, the new version of the Design Sessions website is now live:
>
> https://design-sessions.xenproject.o
On 07/05/2020 14:17, 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 02.05.2020 00:58, Andrew Cooper wrote:
>> We need to unwind up to the supervisor token. See the comment fo
On 05/05/2020 15:48, 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 02.05.2020 00:58, Andrew Cooper wrote:
>> When executing an IRET-to-self, the shadow stack must agree with
On 5/11/20 3:31 AM, Juergen Gross wrote:
> Today xenbus_map_ring_valloc() can return either a negative errno
> value (-ENOMEM or -EINVAL) or a grant status value. This is a mess as
> e.g -ENOMEM and GNTST_eagain have the same numeric value.
>
> Fix that by turning all grant mapping errors into -ENO
On 5/11/20 3:31 AM, Juergen Gross wrote:
>
> static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
I wonder whether we can drop valloc/vfree from xenbus_ring_ops' names.
> + struct map_ring_valloc *info,
> grant
On 04/05/2020 15:24, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -732,14 +732,14 @@ void load_system_tables(void)
>> .rsp2 = 0x8600ul,
>>
>> /*
>> - * M
On 04/05/2020 15:10, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> @@ -1457,6 +1451,10 @@ void do_page_fault(struct cpu_user_regs *regs)
>> {
>> enum pf_type pf_type = spurious_page_fault(addr, regs);
>>
>> +/* Any fault on a shadow stack access is a bug
flight 150133 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 150126
Regressions which a
Jan Beulich writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be
selected from the menuconfig directly"):
> I'm trying to make the point that your patch, to me, looks to be
> trying to overcome a problem for which we have had a solution all
> the time.
Thanks for this clear statement of y
Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be
selected from the menuconfig directly"):
> I am happy this wording.
Thanks for engaging with the commit message issue.
This patch is:
Acked-by: Ian Jackson
with any of the suggested commit message wordings. I trust you
On Mon, May 11, 2020 at 04:50:47PM +0200, Jan Beulich wrote:
> The op has a "is reserved" flag, and hence registration shouldn't
> happen unilaterally.
>
> Fixes: eb3dd90e4089 ("x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for
> PVH Dom0")
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau
On Mon, May 11, 2020 at 01:07:43PM +0200, Roger Pau Monné wrote:
> On Mon, May 11, 2020 at 11:38:49AM +0100, Andrew Cooper wrote:
> > On 11/05/2020 11:17, Roger Pau Monne wrote:
> > > Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
> > > May Be Dispatched Before an Interrupt o
On 04/05/2020 14:52, 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 02.05.2020 00:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -3
Hi George,
On 11/05/2020 16:27, George Dunlap wrote:
On May 11, 2020, at 2:30 PM, Julien Grall wrote:
[CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
unless you have verified the sender and know the content is safe.
Hi Ian,
Thank you for the clarification.
On 0
> On May 11, 2020, at 2:30 PM, Julien Grall wrote:
>
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> Hi Ian,
>
> Thank you for the clarification.
>
> On 07/05/2020 18:01, Ian Jackson wrote:
>
On 04/05/2020 14:20, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -774,10 +774,27 @@ static void do_reserved_trap(struct cpu_user_regs
>> *regs)
>>trapnr, vec_name(trapnr), regs->error_code);
>> }
>>
On 11.05.2020 17:01, Andrew Cooper wrote:
> On 04/05/2020 14:08, Jan Beulich wrote:
>> On 02.05.2020 00:58, Andrew Cooper wrote:
>>> For one, they render the vector in a different base.
>>>
>>> Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
>>> mnemonic, which starts b
On 04/05/2020 14:08, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> For one, they render the vector in a different base.
>>
>> Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
>> mnemonic, which starts bringing the code/diagnostics in line with the Int
On 11.05.2020 16:53, Andrew Cooper wrote:
> On 04/05/2020 13:44, Jan Beulich wrote:
>> On 02.05.2020 00:58, Andrew Cooper wrote:
>>> The only user of this facility is dom_crash_sync_extable() by passing 0 into
>>> asm_domain_crash_synchronous(). The common error cases are already covered
>>> with
On 04/05/2020 13:44, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> The only user of this facility is dom_crash_sync_extable() by passing 0 into
>> asm_domain_crash_synchronous(). The common error cases are already covered
>> with show_page_walk(), leaving only %ss/%fs selector/
The op has a "is reserved" flag, and hence registration shouldn't
happen unilaterally.
Fixes: eb3dd90e4089 ("x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH
Dom0")
Signed-off-by: Jan Beulich
---
v2: Don't treat XEN_PCI_MMCFG_RESERVED clear as an unregistration
request.
--- a/xen/ar
On Mon, May 11, 2020 at 03:46:38PM +0200, Jan Beulich wrote:
> On 08.05.2020 18:08, Roger Pau Monné wrote:
> > On Fri, May 08, 2020 at 05:11:35PM +0200, Jan Beulich wrote:
> >> On 08.05.2020 17:03, Roger Pau Monné wrote:
> >>> On Fri, May 08, 2020 at 02:43:38PM +0200, Jan Beulich wrote:
> ---
On 11/05/2020 15:14, Jan Beulich wrote:
On 11.05.2020 16:11, Julien Grall wrote:
Hi,
On 11/05/2020 15:07, Jan Beulich wrote:
On 11.05.2020 15:57, Julien Grall wrote:
Hi,
On 11/05/2020 14:40, Jan Beulich wrote:
On 11.05.2020 15:30, Julien Grall wrote:
Hi Ian,
Thank you for the clarifica
> On May 11, 2020, at 3:11 PM, Julien Grall wrote:
>
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> Hi,
>
> On 11/05/2020 15:07, Jan Beulich wrote:
>> On 11.05.2020 15:57, Julien Grall wrote:
On 11.05.2020 16:11, Julien Grall wrote:
> Hi,
>
> On 11/05/2020 15:07, Jan Beulich wrote:
>> On 11.05.2020 15:57, Julien Grall wrote:
>>> Hi,
>>>
>>> On 11/05/2020 14:40, Jan Beulich wrote:
On 11.05.2020 15:30, Julien Grall wrote:
> Hi Ian,
>
> Thank you for the clarification.
>>
Hi,
On 11/05/2020 15:07, Jan Beulich wrote:
On 11.05.2020 15:57, Julien Grall wrote:
Hi,
On 11/05/2020 14:40, Jan Beulich wrote:
On 11.05.2020 15:30, Julien Grall wrote:
Hi Ian,
Thank you for the clarification.
On 07/05/2020 18:01, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH RESEN
On 11.05.2020 15:57, Julien Grall wrote:
> Hi,
>
> On 11/05/2020 14:40, Jan Beulich wrote:
>> On 11.05.2020 15:30, Julien Grall wrote:
>>> Hi Ian,
>>>
>>> Thank you for the clarification.
>>>
>>> On 07/05/2020 18:01, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow E
Hi,
On 11/05/2020 14:40, Jan Beulich wrote:
On 11.05.2020 15:30, Julien Grall wrote:
Hi Ian,
Thank you for the clarification.
On 07/05/2020 18:01, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected
from the menuconfig directly"):
On 04/05/
On 08.05.2020 18:08, Roger Pau Monné wrote:
> On Fri, May 08, 2020 at 05:11:35PM +0200, Jan Beulich wrote:
>> On 08.05.2020 17:03, Roger Pau Monné wrote:
>>> On Fri, May 08, 2020 at 02:43:38PM +0200, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -558,6
On Mon, May 04, 2020 at 12:14:43PM +0200, Roger Pau Monne wrote:
> has_igd_gfx_passthru is only available when QEMU is built with
> CONFIG_XEN_PCI_PASSTHROUGH, and hence shouldn't be used in common
> code without checking if it's available.
>
> Fixes: 46472d82322d0 ('xen: convert "-machine igd-pas
On 11.05.2020 15:30, Julien Grall wrote:
> Hi Ian,
>
> Thank you for the clarification.
>
> On 07/05/2020 18:01, Ian Jackson wrote:
>> Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be
>> selected from the menuconfig directly"):
>>> On 04/05/2020 13:34, Ian Jackson wrote:
Hi Ian,
Thank you for the clarification.
On 07/05/2020 18:01, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected
from the menuconfig directly"):
On 04/05/2020 13:34, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH RESEND 2/2] xen: Allow
On 11.05.2020 12:31, Roger Pau Monne wrote:
> Add entries for the relevant changes I've been working on during the
> 4.14 development time frame. Mostly performance improvements related
> to pvshim scalability issues when running with high number of vCPUs.
>
> Signed-off-by: Roger Pau Monné
> ---
flight 150134 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150134/
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
flight 150130 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 150104
Regressions which are
> -Original Message-
> From: Roger Pau Monne
> Sent: 11 May 2020 11:32
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Paul Durrant ;
> Community Manager
>
> Subject: [PATCH] changelog: add relevant changes during 4.14 development
> window
>
> Add entries for the relevant
With RCU barriers moved from tasklets to normal RCU processing cpu
offlining in core scheduling might deadlock due to cpu synchronization
required by RCU processing and core scheduling concurrently.
Fix that by bailing out from core scheduling synchronization in case
of pending RCU work. Additiona
Some problems I found when trying to find a problem with
cpu-on/offlining in core scheduling mode.
Juergen Gross (3):
xen/sched: allow rcu work to happen when syncing cpus in core
scheduling
xen/sched: don't call sync_vcpu_execstate() in
sched_unit_migrate_finish()
xen/sched: fix lat
The dirty_cpu field of struct vcpu denotes which cpu still holds data
of a vcpu. All accesses to this field should be atomic in case the
vcpu could just be running, as it is accessed without any lock held
in most cases. Especially sync_local_execstate() and context_switch()
for the same vcpu runnin
With support of core scheduling sched_unit_migrate_finish() gained a
call of sync_vcpu_execstate() as it was believed to be called as a
result of vcpu migration in any case.
In case of migrating a vcpu away from a physical cpu for a short period
of time only this might not be true, so drop the cal
On Mon, May 11, 2020 at 11:38:49AM +0100, Andrew Cooper wrote:
> On 11/05/2020 11:17, Roger Pau Monne wrote:
> > Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
> > May Be Dispatched Before an Interrupt of The Same Priority Completes".
> >
> > It's not clear which models are a
On Thu, 2020-04-30 at 17:15 +0200, Jan Beulich wrote:
> On 24.04.2020 16:09, Hongyan Xia wrote:
> > From: Wei Liu
>
> Nit: Why the emphasis on pl*e in the title? Is there anything left
> unconverted in the function? IOW how about "switch clone_mapping()
> to new page table APIs"?
The title seems
On 08.05.2020 19:24, Roger Pau Monné wrote:
> On Fri, May 08, 2020 at 03:46:08PM +0200, Jan Beulich wrote:
>> On 07.05.2020 15:22, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/cpu/mwait-idle.c
>>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>>> @@ -770,6 +770,9 @@ static void mwait_idle(void)
>>>
flight 150131 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 11/05/2020 11:17, Roger Pau Monne wrote:
> Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
> May Be Dispatched Before an Interrupt of The Same Priority Completes".
>
> It's not clear which models are affected, as the errata is listed in
> the "Second Generation Intel Xeon S
Add entries for the relevant changes I've been working on during the
4.14 development time frame. Mostly performance improvements related
to pvshim scalability issues when running with high number of vCPUs.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 6 ++
1 file changed, 6 insertions(
Hi Andrew,
On 11/05/2020 11:10, Andrew Cooper wrote:
On 11/05/2020 10:34, Julien Grall wrote:
Hi Volodymyr,
On 06/05/2020 02:44, Volodymyr Babchuk wrote:
Normal World can share buffer with OP-TEE for two reasons:
1. Some client application wants to exchange data with TA
2. OP-TEE asks for sha
Remove the eax and cstate local variables, the same can be directly
fetched from acpi_processor_cx without any transformations.
No functional change.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/mwait-idle.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/
Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
May Be Dispatched Before an Interrupt of The Same Priority Completes".
It's not clear which models are affected, as the errata is listed in
the "Second Generation Intel Xeon Scalable Processors" specification
update, but the iss
flight 150128 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150128/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150119
test-armhf-armhf-libvirt 14 save
On 11/05/2020 10:34, Julien Grall wrote:
> Hi Volodymyr,
>
> On 06/05/2020 02:44, Volodymyr Babchuk wrote:
>> Normal World can share buffer with OP-TEE for two reasons:
>> 1. Some client application wants to exchange data with TA
>> 2. OP-TEE asks for shared buffer for internal needs
>>
>> The seco
Hi Volodymyr,
On 06/05/2020 02:44, Volodymyr Babchuk wrote:
Normal World can share buffer with OP-TEE for two reasons:
1. Some client application wants to exchange data with TA
2. OP-TEE asks for shared buffer for internal needs
The second case was handle more strictly than necessary:
1. In RP
On Mon, May 11, 2020 at 09:29:27AM +0200, Jan Beulich wrote:
> On 08.05.2020 18:21, Roger Pau Monné wrote:
> > On Fri, May 08, 2020 at 05:04:02PM +0200, Jan Beulich wrote:
> >> On 08.05.2020 15:37, Roger Pau Monné wrote:
> >>> On Tue, May 05, 2020 at 10:16:20AM +0200, Jan Beulich wrote:
> ---
On 09.05.20 00:28, Boris Ostrovsky wrote:
Commit a926f81d2f6c ("xen/cpuhotplug: Replace cpu_up/down() with
device_online/offline()") replaced cpu_down() with device_offline()
call which requires that the CPU has been registered before. This
registration, however, happens later from topology_init(
Ping?
On Mon, May 04, 2020 at 12:14:43PM +0200, Roger Pau Monne wrote:
> has_igd_gfx_passthru is only available when QEMU is built with
> CONFIG_XEN_PCI_PASSTHROUGH, and hence shouldn't be used in common
> code without checking if it's available.
>
> Fixes: 46472d82322d0 ('xen: convert "-machine
On 09.05.20 15:47, Rikard Falkeborn wrote:
dev_pm_ops is never modified, so mark it const to allow the compiler to
put it in read-only memory.
Before:
textdata bss dec hex filename
24571668 2564381111d drivers/xen/platform-pci.o
After:
textdata
On Mon, May 11, 2020 at 09:25:54AM +0200, 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 08.05.2020 20:29, Andrew Cooper wrote:
> > On 08/05/2020 16:04, Jan Beulich wrote:
>
On 08.05.2020 17:27, Andrew Cooper wrote:
> @@ -133,9 +134,13 @@ def crunch_numbers(state):
> state.hvm_shadow_def = state.pv_def | state.raw['S']
> state.hvm_hap_def = state.hvm_shadow_def | state.raw['H']
>
> +# TODO: Ignore def/max split until the toolstack migration logic is fix
backend_connect() can fail, so switch the device to connected only if
no error occurred.
Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
drivers/xen/pvcalls-back.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
d
xenbus_map_ring_valloc() and its sub-functions are putting quite large
structs and arrays on the stack. This is problematic at runtime, but
might also result in build failures (e.g. with clang due to the option
-Werror,-Wframe-larger-than=... used).
Fix that by moving most of the data from the sta
Today xenbus_map_ring_valloc() can return either a negative errno
value (-ENOMEM or -EINVAL) or a grant status value. This is a mess as
e.g -ENOMEM and GNTST_eagain have the same numeric value.
Fix that by turning all grant mapping errors into -ENOENT. This is
no problem as all callers of xenbus_m
Avoid allocating large amount of data on the stack in
xenbus_map_ring_valloc() and some related return value cleanups.
Juergen Gross (2):
xen/xenbus: avoid large structs and arrays on the stack
xen/xenbus: let xenbus_map_ring_valloc() return errno values only
drivers/xen/xenbus/xenbus_client
On 08.05.2020 18:21, Roger Pau Monné wrote:
> On Fri, May 08, 2020 at 05:04:02PM +0200, Jan Beulich wrote:
>> On 08.05.2020 15:37, Roger Pau Monné wrote:
>>> On Tue, May 05, 2020 at 10:16:20AM +0200, Jan Beulich wrote:
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x
On 08.05.2020 20:29, Andrew Cooper wrote:
> On 08/05/2020 16:04, Jan Beulich wrote:
+}
+
+if ( bytes == sizeof(fpstate.env) )
+ptr = NULL;
+else
+ptr += sizeof(fpstate.env);
+break;
>>
82 matches
Mail list logo
