On 07/22/19 19:06, Anthony PERARD wrote:
> On Wed, Jul 10, 2019 at 12:48:57PM +0200, Laszlo Ersek wrote:
>> On 07/04/19 16:42, Anthony PERARD wrote:
>>> On a Xen PVH guest, none of the existing serial or console interface
>>> works, so we add a new one, based on XenConsoleSerialPortLib, and
>>> imp
> On 12 Jul 2019, at 13:24, Peter Robinson wrote:
>
> On Fri, Jul 12, 2019 at 5:50 AM David Woodhouse wrote:
>>
>>
>>> IIRC, what we have right now is a somewhat vague setup where we just
>>> have 'local', 'ec2' and 'openstack' columns. The instructions for
>>> "Amazon Web Services" just say
On 22.07.2019 17:43, Andrew Cooper wrote:
> On 22/07/2019 16:01, Jan Beulich wrote:
>> On 22.07.2019 15:36, Andrew Cooper wrote:
>>> On 22/07/2019 09:34, Jan Beulich wrote:
On 19.07.2019 19:27, Andrew Cooper wrote:
> On 16/07/2019 17:38, Jan Beulich wrote:
>> @@ -142,7 +178,15 @@ stati
On 19.07.2019 16:18, Jan Beulich wrote:
> On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
>> On 18.07.2019 15:58, Jan Beulich wrote:
>>> On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
Currently, we are fully emulating the instruction at RIP when the hardware
sees
an EPT
On 23.07.2019 10:13, Jan Beulich wrote:
> On 22.07.2019 17:43, Andrew Cooper wrote:
>> How would your argument change if the IOMMU was a real CPU running real
>> x86 code? Its interface to the rest of the system would be identical,
>> and in that case, it would obviously need an smp_{r,w}mb() pair
Julien, Jan, Andrew,
The problem addressed by [1] causes random ARM64 boot fails dependent on
hypervisor code changes.
Yet more generic solution was requested by Andrew and supported by Julien [2].
How to proceed with this particular patch?
As I understand, Jan doubts we should move page alignm
Hi,
Awaited for your input.
Regards,
Sushant
From: Sushant Bhangale
Sent: Friday, July 12, 2019 7:52 PM
To: xen-devel@lists.xenproject.org
Cc: Pranav Paralikar ; Nikhil Wadke
; sstabell...@kernel.org; julien.gr...@arm.com;
lars.ku...@citrix.com
Subject: Xen Hypervisor porting on Raspberry Pi 3
flight 139249 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139249/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 139237
Tests which did not
On Mon, Jul 22, 2019 at 09:28:20PM +0200, Laszlo Ersek wrote:
> On 07/22/19 15:49, Anthony PERARD wrote:
> > On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné wrote:
> >> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
> >>> ACPI Timer does not work in a PVH guest, but local
flight 139251 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail REGR. vs. 139230
Tests which did n
On 23.07.2019 10:48, Andrii Anisov wrote:
> Julien, Jan, Andrew,
>
> The problem addressed by [1] causes random ARM64 boot fails dependent on
> hypervisor code changes.
> Yet more generic solution was requested by Andrew and supported by Julien [2].
>
> How to proceed with this particular patch?
Commit 0763cd2687897b55e7 ("xen/sched: don't disable scheduler on cpus
during suspend") removed a lock in restore_vcpu_affinity() which needs
to stay: cpumask_scratch_cpu() must be protected by the scheduler
lock. restore_vcpu_affinity() is being called by thaw_domains(), so
with multiple domains i
Today there are three scenarios which are pinning vcpus temporarily to
a single physical cpu:
- NMI/MCE injection into PV domains
- wait_event() handling
- vcpu_pin_override() handling
Each of those cases are handled independently today using their own
temporary cpumask to save the old affinity s
While trying to handle temporary vcpu pinnings in a sane way in my
core scheduling series I stumbled over a bug and found a nice way to
simplify the temporary pinning cases.
I'm sending the two patches independently from my core scheduling
series as they should be considered even without core sche
On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > When running as a Xen PVH guest, there is no CMOS to read the memory
> > > size from. Rework
Hello Jan,
On 23.07.19 12:12, Jan Beulich wrote:
Beyond that I continue to be of the opinion that it should be
all-or-nothing: Any pointer pointing anywhere at or inside the
region should be accepted, or just the one pointing precisely at
the start.
It's reasonable enough and I agree with that
On 19.07.2019 16:07, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> While there convert {IGD/IOH}_DEV to be a pci_sbdf_t itself instead of
> a device number.
>
> Signed-off-by: Roger Pau Monné
> Acked-by: Bri
On 19.07.2019 16:07, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@l
On 22.07.2019 17:32, Roger Pau Monne wrote:
> The current usage of need_iommu_pt_sync in p2m for non-translated
> guests is wrong because it doesn't correctly handle a relaxed PV
> hardware domain, that has need_sync set to false, but still need
> entries to be added from calls to {set/clear}_ident
On 22.07.2019 17:45, Roger Pau Monne wrote:
> Clarify why relaxed hardware domains don't need iommu page-table
> syncing.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
On Tue, 2019-07-23 at 11:20 +0200, Juergen Gross wrote:
> Commit 0763cd2687897b55e7 ("xen/sched: don't disable scheduler on
> cpus
> during suspend") removed a lock in restore_vcpu_affinity() which
> needs
> to stay: cpumask_scratch_cpu() must be protected by the scheduler
> lock.
>
And indeed I r
On Tue, Jul 23, 2019 at 10:15:35AM +, Jan Beulich wrote:
> On 19.07.2019 16:07, Roger Pau Monne wrote:
> > This reduces the number of parameters of the function to two, and
> > simplifies some of the calling sites.
> >
> > While there convert {IGD/IOH}_DEV to be a pci_sbdf_t itself instead of
On 18/07/2019 14:18, Viktor Mitin wrote:
Hi Julien,
Hi,
I've checked latest Xen staging, the patch has not been integrated yet.
Please integrate the patch if no objections.
Done now. Sorry for the delay.
Cheers,
--
Julien Grall
___
Xen-devel m
On 23.07.19 14:08, Jan Beulich wrote:
On 23.07.2019 11:20, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -708,6 +708,8 @@ void restore_vcpu_affinity(struct domain *d)
* set v->processor of each of their vCPUs to something that will
* make
On 23.07.2019 11:20, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -708,6 +708,8 @@ void restore_vcpu_affinity(struct domain *d)
>* set v->processor of each of their vCPUs to something that will
>* make sense for the scheduler of the c
On 23/07/2019 10:20, Juergen Gross wrote:
> Today there are three scenarios which are pinning vcpus temporarily to
> a single physical cpu:
>
> - NMI/MCE injection into PV domains
> - wait_event() handling
> - vcpu_pin_override() handling
>
> Each of those cases are handled independently today usin
On Tue, Jul 23, 2019 at 10:32:41AM +, Jan Beulich wrote:
> On 22.07.2019 17:32, Roger Pau Monne wrote:
> > The current usage of need_iommu_pt_sync in p2m for non-translated
> > guests is wrong because it doesn't correctly handle a relaxed PV
> > hardware domain, that has need_sync set to false,
The current usage of need_iommu_pt_sync in p2m for non-translated
guests is wrong because it doesn't correctly handle a relaxed PV
hardware domain, that has need_sync set to false, but still need
entries to be added from calls to {set/clear}_identity_p2m_entry.
Signed-off-by: Roger Pau Monné
Revi
On 23.07.2019 11:20, Juergen Gross wrote:
> Today there are three scenarios which are pinning vcpus temporarily to
> a single physical cpu:
>
> - NMI/MCE injection into PV domains
> - wait_event() handling
> - vcpu_pin_override() handling
>
> Each of those cases are handled independently today us
On 23.07.2019 14:43, Roger Pau Monne wrote:
> The current usage of need_iommu_pt_sync in p2m for non-translated
> guests is wrong because it doesn't correctly handle a relaxed PV
> hardware domain, that has need_sync set to false, but still need
> entries to be added from calls to {set/clear}_ident
On 23/07/2019 13:08, Jan Beulich wrote:
> On 23.07.2019 11:20, Juergen Gross wrote:
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -708,6 +708,8 @@ void restore_vcpu_affinity(struct domain *d)
>>* set v->processor of each of their vCPUs to something that will
>>
On Tue, 2019-07-23 at 11:20 +0200, Juergen Gross wrote:
> Today there are three scenarios which are pinning vcpus temporarily
> to
> a single physical cpu:
>
> - NMI/MCE injection into PV domains
> - wait_event() handling
> - vcpu_pin_override() handling
>
> Each of those cases are handled indepe
On Tue, 2019-07-23 at 12:42 +, Jan Beulich wrote:
> On 23.07.2019 11:20, Juergen Gross wrote:
> > Today there are three scenarios which are pinning vcpus temporarily
> > to
> > a single physical cpu:
> >
> > - NMI/MCE injection into PV domains
> > - wait_event() handling
> > - vcpu_pin_overrid
On 23.07.19 14:26, Andrew Cooper wrote:
On 23/07/2019 10:20, Juergen Gross wrote:
Today there are three scenarios which are pinning vcpus temporarily to
a single physical cpu:
- NMI/MCE injection into PV domains
- wait_event() handling
- vcpu_pin_override() handling
Each of those cases are han
On 23/07/2019 14:25, Juergen Gross wrote:
> On 23.07.19 14:26, Andrew Cooper wrote:
>> On 23/07/2019 10:20, Juergen Gross wrote:
>>
>>> }
>>> /*
>>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>>> index b40c8fd138..721c429454 100644
>>> --- a/xen/include/xen/sched.h
Hi Oleksandr,
On 22/07/2019 17:27, Oleksandr wrote:
On 20.07.19 21:25, Julien Grall wrote:
Apologies for the late answer. I have been traveling for the past few weeks.
Absolutely no problem. Thank you for your review.
On 6/26/19 11:30 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshc
On 23/07/2019 05:36, Juergen Gross wrote:
> On 22.07.19 21:20, Andrew Cooper wrote:
>> diff --git a/docs/misc/wishlist.rst b/docs/misc/wishlist.rst
>> new file mode 100644
>> index 00..6cdb47d6e7
>> --- /dev/null
>> +++ b/docs/misc/wishlist.rst
>> @@ -0,0 +1,53 @@
>> +Development Wishlist
>
On 23.07.19 14:42, Jan Beulich wrote:
On 23.07.2019 11:20, Juergen Gross wrote:
Today there are three scenarios which are pinning vcpus temporarily to
a single physical cpu:
- NMI/MCE injection into PV domains
- wait_event() handling
- vcpu_pin_override() handling
Each of those cases are handl
On 22/07/2019 20:20, Andrew Cooper wrote:
> a.k.a. (at least in this form) Andrew's "work which might be offloadable to
> someone else" list.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
On 23.07.2019 15:44, Juergen Gross wrote:
> On 23.07.19 14:42, Jan Beulich wrote:
>> v->processor gets latched into st->processor before raising the softirq,
>> but can't the vCPU be moved elsewhere by the time the softirq handler
>> actually gains control? If that's not possible (and if it's not o
On 23.07.19 15:31, Andrew Cooper wrote:
On 23/07/2019 14:25, Juergen Gross wrote:
On 23.07.19 14:26, Andrew Cooper wrote:
On 23/07/2019 10:20, Juergen Gross wrote:
}
/*
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b40c8fd138..721c429454 100644
--- a/xen
On 23.07.2019 16:03, Jan Beulich wrote:
> On 23.07.2019 15:44, Juergen Gross wrote:
>> On 23.07.19 14:42, Jan Beulich wrote:
>>> v->processor gets latched into st->processor before raising the softirq,
>>> but can't the vCPU be moved elsewhere by the time the softirq handler
>>> actually gains cont
On 23.07.19 16:14, Jan Beulich wrote:
On 23.07.2019 16:03, Jan Beulich wrote:
On 23.07.2019 15:44, Juergen Gross wrote:
On 23.07.19 14:42, Jan Beulich wrote:
v->processor gets latched into st->processor before raising the softirq,
but can't the vCPU be moved elsewhere by the time the softirq h
flight 139257 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-
On 23/07/2019 15:14, Juergen Gross wrote:
> On 23.07.19 15:31, Andrew Cooper wrote:
>> On 23/07/2019 14:25, Juergen Gross wrote:
>>> On 23.07.19 14:26, Andrew Cooper wrote:
On 23/07/2019 10:20, Juergen Gross wrote:
> }
> /*
> diff --git a/xen/include/xen/sched.
On 23.07.19 16:14, Jan Beulich wrote:
On 23.07.2019 16:03, Jan Beulich wrote:
On 23.07.2019 15:44, Juergen Gross wrote:
On 23.07.19 14:42, Jan Beulich wrote:
v->processor gets latched into st->processor before raising the softirq,
but can't the vCPU be moved elsewhere by the time the softirq h
On 23.07.19 15:07, Dario Faggioli wrote:
On Tue, 2019-07-23 at 11:20 +0200, Juergen Gross wrote:
Today there are three scenarios which are pinning vcpus temporarily
to
a single physical cpu:
- NMI/MCE injection into PV domains
- wait_event() handling
- vcpu_pin_override() handling
Each of thos
On 23.07.2019 16:29, Juergen Gross wrote:
> On 23.07.19 16:14, Jan Beulich wrote:
>> On 23.07.2019 16:03, Jan Beulich wrote:
>>> On 23.07.2019 15:44, Juergen Gross wrote:
On 23.07.19 14:42, Jan Beulich wrote:
> v->processor gets latched into st->processor before raising the softirq,
>
On 23.07.19 17:04, Jan Beulich wrote:
On 23.07.2019 16:29, Juergen Gross wrote:
On 23.07.19 16:14, Jan Beulich wrote:
On 23.07.2019 16:03, Jan Beulich wrote:
On 23.07.2019 15:44, Juergen Gross wrote:
On 23.07.19 14:42, Jan Beulich wrote:
v->processor gets latched into st->processor before ra
On 23/07/2019 16:22, Juergen Gross wrote:
> On 23.07.19 17:04, Jan Beulich wrote:
>> On 23.07.2019 16:29, Juergen Gross wrote:
>>> On 23.07.19 16:14, Jan Beulich wrote:
On 23.07.2019 16:03, Jan Beulich wrote:
> On 23.07.2019 15:44, Juergen Gross wrote:
>> On 23.07.19 14:42, Jan Beulich
On 23.07.19 15:38, Andrew Cooper wrote:
On 23/07/2019 05:36, Juergen Gross wrote:
On 22.07.19 21:20, Andrew Cooper wrote:
diff --git a/docs/misc/wishlist.rst b/docs/misc/wishlist.rst
new file mode 100644
index 00..6cdb47d6e7
--- /dev/null
+++ b/docs/misc/wishlist.rst
@@ -0,0 +1,53 @@
+D
Current code only prevent mapping the lapic page into the guest
physical memory map. Expand the range to be 0xFEEx_ as described
in the Intel VTd specification section 3.13 "Handling Requests to
Interrupt Address Range".
AMD also lists this address range in the AMD SR5690 Databook, section
2.4
Current code only prevents mapping the io-apic page into the guest
physical memory map. Expand the range to be 0xFECx_ as described
in the Intel 3 Series Chipset Datasheet section 3.3.1 "APIC
Configuration Space (FEC0_h–FECF_h)".
AMD also lists this address range in the AMD SR5690 Data
Hello,
The following series contains two small fixes to hwdom_iommu_map in
order to expand the forbidden ranges to cover the full Interrupt Address
Range and the APIC Configuration Space.
Thanks, Roger.
Roger Pau Monne (2):
x86/iommu: avoid mapping the interrupt address range for hwdom
x86/i
flight 139282 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139282/
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 23.07.19 17:29, Andrew Cooper wrote:
On 23/07/2019 16:22, Juergen Gross wrote:
On 23.07.19 17:04, Jan Beulich wrote:
On 23.07.2019 16:29, Juergen Gross wrote:
On 23.07.19 16:14, Jan Beulich wrote:
On 23.07.2019 16:03, Jan Beulich wrote:
On 23.07.2019 15:44, Juergen Gross wrote:
On 23.07.
flight 139262 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139262/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb824f685d760f560bb3c3fb14af394ab3b3544f
baseline version:
ovmf 5f89bcc4604ea9e439039
On 23/07/2019 16:53, Juergen Gross wrote:
> On 23.07.19 17:29, Andrew Cooper wrote:
>> On 23/07/2019 16:22, Juergen Gross wrote:
>>> On 23.07.19 17:04, Jan Beulich wrote:
On 23.07.2019 16:29, Juergen Gross wrote:
> On 23.07.19 16:14, Jan Beulich wrote:
>> On 23.07.2019 16:03, Jan Beuli
On 23.07.2019 17:22, Juergen Gross wrote:
> On 23.07.19 17:04, Jan Beulich wrote:
>> On 23.07.2019 16:29, Juergen Gross wrote:
>>> On 23.07.19 16:14, Jan Beulich wrote:
Oh, no. The #MC side use has gone away in 3a91769d6e, without cleaning
up other code. So there doesn't seem to be any su
The flag is not needed since the domain 'createflags' can now be tested
directly.
Signed-off-by: Paul Durrant
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/mm/shadow/common.c | 3 +--
xen/include/asm-x86/domain.h
The enum guest_type was introduced in commit 6c6492780ea "pvh prep:
introduce pv guest type and has_hvm_container macros" to allow a new guest
type, distinct from either PV or HVM guest types, to be added in commit
8271d6522c6 "pvh: introduce PVH guest type". Subsequently, commit
33e5c32559e "x86:
This patch introduces a convenience macro, is_xenstore_domain(), which
tests the domain 'createflags' directly and then uses that in place of
the 'is_xenstore' flag.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konra
The flag is not needed since the domain 'createflags' can now be tested
directly.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Gang Wei
Cc: Shane Wang
---
xen/arch/x86/domain.c| 2 --
xen/arch/x86/tboot.c | 2 +-
xe
These are canonical source of data used to set various other flags. If
they are available directly in struct domain then the other flags are no
longer needed.
This patch simply copies the flags into a new 'createflags' field in
struct domain. Subsequent patches will do the related clean-up work.
The hap_enabled() macro can determine whether the feature is available
using the domain 'createflags'; there is no need for a separate flag.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/domain.c| 7 +--
x
This series starts with a patch to stash the domain create flags in struct
domain then then follows up with various clean-up patches that this
enables.
Paul Durrant (6):
domain: stash xen_domctl_createdomain flags in struct domain
domain: remove 'guest_type' field (and enum guest_type)
x86/h
On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > You could maybe initial
On 23.07.2019 17:48, Roger Pau Monne wrote:
> Current code only prevent mapping the lapic page into the guest
> physical memory map. Expand the range to be 0xFEEx_ as described
> in the Intel VTd specification section 3.13 "Handling Requests to
> Interrupt Address Range".
Right, and it being d
On 23.07.2019 17:48, Roger Pau Monne wrote:
> Current code only prevents mapping the io-apic page into the guest
> physical memory map. Expand the range to be 0xFECx_ as described
> in the Intel 3 Series Chipset Datasheet section 3.3.1 "APIC
> Configuration Space (FEC0_h–FECF_h)".
>
>
On 23/07/2019 17:09, Jan Beulich wrote:
> On 23.07.2019 17:48, Roger Pau Monne wrote:
>> Current code only prevents mapping the io-apic page into the guest
>> physical memory map. Expand the range to be 0xFECx_ as described
>> in the Intel 3 Series Chipset Datasheet section 3.3.1 "APIC
>> Confi
Hi Jan,
On 23/07/2019 10:12, Jan Beulich wrote:
On 23.07.2019 10:48, Andrii Anisov wrote:
Julien, Jan, Andrew,
The problem addressed by [1] causes random ARM64 boot fails dependent on
hypervisor code changes.
Yet more generic solution was requested by Andrew and supported by Julien [2].
How
flight 139259 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139259/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139239
test-amd64-i386-xl-qemuu-win7-amd64
Hi Roger!
I applied your patch, removed no-igfx and I still see the original
problem. Please let me know what other logs/debugs would you need at
this point.
Btw, just to make it clear what patch got applied I'm attaching it to
this email.
Oh, and it seems that that https://downloads.xenproject.
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Hi Roger!
>
> I applied your patch, removed no-igfx and I still see the original
> problem. Please let me know what other logs/debugs would you need at
> this point.
Please can you collect a full boot log with iommu=debug
~Andrew
___
On 23/07/2019 18:48, Roman Shaposhnik wrote:
> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> wrote:
>> On 23/07/2019 18:32, Roman Shaposhnik wrote:
>>> Hi Roger!
>>>
>>> I applied your patch, removed no-igfx and I still see the original
>>> problem. Please let me know what other logs/debugs wou
It would be great to have Xen running on RPi, but I have to wonder: is
it now possible to workaround RPi limitations of how GPU boots?
https://www.raspberrypi.org/forums/viewtopic.php?t=187086#p1206487
I thought that this is completely locked, proprietary bcm2837 code
that Xen can't do much of
On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
wrote:
>
> On 23/07/2019 18:48, Roman Shaposhnik wrote:
> > On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> > wrote:
> >> On 23/07/2019 18:32, Roman Shaposhnik wrote:
> >>> Hi Roger!
> >>>
> >>> I applied your patch, removed no-igfx and I still see
On 23/07/2019 18:58, Roman Shaposhnik wrote:
> On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
> wrote:
>> On 23/07/2019 18:48, Roman Shaposhnik wrote:
>>> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
>>> wrote:
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Hi Roger!
>
> I appl
flight 139290 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139290/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Today there are two scenarios which are pinning vcpus temporarily to
a single physical cpu:
- wait_event() handling
- vcpu_pin_override() handling
Each of those cases are handled independently today using their own
temporary cpumask to save the old affinity settings.
The two cases can be combine
While trying to handle temporary vcpu pinnings in a sane way in my
core scheduling series I found a nice way to simplify the temporary
pinning cases.
I'm sending the two patches independently from my core scheduling
series as they should be considered even without core scheduling.
Changes in V2:
pv_raise_interrupt() is only called for NMIs these days, so the MCE
specific part can be removed. Rename pv_raise_interrupt() to
pv_raise_nmi() and NMI_MCE_SOFTIRQ to NMI_SOFTIRQ.
Additionally there is no need to pin the vcpu the NMI is delivered
to, that is a leftover of (already removed) MCE han
On Tue, Jul 23, 2019 at 11:12 AM Andrew Cooper
wrote:
>
> On 23/07/2019 18:58, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
> wrote:
>
> On 23/07/2019 18:48, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> wrote:
>
> On 23/07/2019 18:32,
On 23/07/2019 19:25, Juergen Gross wrote:
> pv_raise_interrupt() is only called for NMIs these days, so the MCE
> specific part can be removed. Rename pv_raise_interrupt() to
> pv_raise_nmi() and NMI_MCE_SOFTIRQ to NMI_SOFTIRQ.
For posterity, it would be helpful to explicitly identify 355b0469a8
w
On 23/07/2019 19:25, Juergen Gross wrote:
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 349f9624f5..508176a142 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1106,43 +1106,59 @@ void watchdog_domain_destroy(struct domain *d)
> kill_timer(&d-
On 23/07/2019 16:30, Juergen Gross wrote:
> On 23.07.19 15:38, Andrew Cooper wrote:
>> On 23/07/2019 05:36, Juergen Gross wrote:
>>> On 22.07.19 21:20, Andrew Cooper wrote:
diff --git a/docs/misc/wishlist.rst b/docs/misc/wishlist.rst
new file mode 100644
index 00..6cdb47d6e7
All callers are in pv/iret.c. Move the function and make it static.
Even before the pinning cleanup, there was nothing which is specific to
operating on curr, so rename the variable back to v.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Mo
Hello,
On Wed, Jul 10, 2019 at 07:44:08PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: fix pci device
> re-assigning after domain reboot"):
> > On Wed, Jun 26, 2019 at 03:37:26PM +0200, Juergen Gross wrote:
> > > Signed-off-by: Juergen Gross
> > > Tested-by
Hi,
On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
> All,
>
> the release is due in early August. Please point out backports you
> find missing from the respective staging branch, but which you
> consider relevant. The one commit I've queued already on top of
> what was just pushed
flight 139268 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139268/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On Tue, Jul 23, 2019 at 2:00 PM Pasi Kärkkäinen wrote:
>
> Hi,
>
> On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
> > All,
> >
> > the release is due in early August. Please point out backports you
> > find missing from the respective staging branch, but which you
> > consider releva
psr_mode_is_32bit() prototype does not match the rest of the helpers for
the process state. Looking at the callers, most of them will access
struct cpu_user_regs just for calling psr_mode_is_32bit().
The macro is now reworked to take a struct cpu_user_regs in parameter.
At the same time take the o
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed by the tools and Xen. It is also
not expected to be ever used outside of that context. So we could save us
som
On Arm64, the SMCCC function identifier is always stored in the first 32-bit
of x0 register. The rest of the bits are not defined and should be
ignored.
This means the variable funcid should be an uint32_t rather than
register_t.
Signed-off-by: Julien Grall
---
xen/arch/arm/vsmc.c | 4 ++--
1 f
Hi all,
This is a not-yet complete series to harden Xen for later revision of
Armv8. The main goals are:
- Reducing the number of BUG_ON() to check guest state
- Fix system registers size as they are always 64-bit on AArch64
(not 32-bit!).
There are more work to do. I will send them i
At the moment, do_trap_brk() is using a BUG_ON() to check the hardware
has been correctly configured during boot.
Any error when configuring the hardware could result to a guest 'brk'
trapping in the hypervisor and crash it.
This is pretty harsh to kill Xen when actually killing the guest would
b
The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
64-bit). However, some of the users uses the wrong padding.
For more consistency, the padding is now moved into the PRIregister and
varies depending on the architecture.
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c
At the moment, _show_registers() is using a BUG_ON() to assert only
userspace will run 32-bit code in a 64-bit domain.
Such extra precaution is not necessary and could be avoided by only
checking the CPU mode to decide whether show_registers_64() or
show_reigsters_32() should be called.
This has
On Arm64, system registers are always 64-bit including SCTLR_EL1.
However, Xen is assuming this is 32-bit because earlier revision of
Armv8 had the top 32-bit RES0 (see ARM DDI0595.b).
From Armv8.5, some bits in [63:32] will be defined and allowed to be
modified by the guest. So we would effective
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
> On Thu, 2019-07-11 at 21:43 +0100, Peter Robinson wrote:
> > > On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote:
> > > > It's worth noting that at least part of the justification for the
> > > > criterion in the first place was tha
1 - 100 of 112 matches
Mail list logo
