On Fri, Nov 30, 2018 at 02:53:50PM +, Hans van Kranenburg wrote:
> On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
> > On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
> >> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen
George Dunlap writes ("Re: [PATCH 7/9] libxl: Make killing of device model
asynchronous"):
> It looks cleaner to me to have *something* there than not, just to visually
> make it clear that it has nothing to do with the previous function.
That's OK by me.
Ian.
George Dunlap writes ("Re: [PATCH 7/9] libxl: Make killing of device model
asynchronous"):
> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
> > Conversely it would be nice to say somewhere
> > that ddms->callback may be called reentrantly.
>
> What do you mean by reentrantly? That
flight 130844 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
On 11/30/18 4:46 AM, Jan Beulich wrote:
On 29.11.18 at 23:43, wrote:
>> One other comment about this patch (which IIRC was raised by Andrew on
>> an earlier version) is that it may be worth to stop timer calibration. I
>> am pretty sure we've seen deadlocks, which is why we ended up
On Fri, Nov 30, 2018 at 12:53:20PM +, George Dunlap wrote:
>
>
> > On Nov 28, 2018, at 3:32 PM, Wei Liu wrote:
> >
> > On Fri, Nov 23, 2018 at 05:14:56PM +, George Dunlap wrote:
> >> QEMU_USER_BASE allows a user to specify the UID to use when running
> >> the devicemodel for a specific
On Fri, Nov 30, 2018 at 05:07:20PM +, Andy Cooper wrote:
> For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
> supports the instruction, but the guest may have not have rdtscp in its
> featureset. Bring the vmexit handlers in line with the main emulator
> behaviour by
On 11/30/18 5:21 PM, Kirill A. Shutemov wrote:
> On Fri, Nov 30, 2018 at 02:53:50PM +, Hans van Kranenburg wrote:
>> On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
>>> On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
>
Hi Jan, hi Juergen,
I'm trying again this week to install Xen on a OVH server
(https://www.ovh.com/fr/serveurs_dedies/infra/1801eg02.xml).
It is still impossible to boot Xen with the option "dom0_mem=1G,max:1G"
(boot : EFI->xen).
I have tried with Debian 9 stable/stretch :
- grub2
flight 130877 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130877/
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
On Fri, Nov 30, 2018 at 05:09:42PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> > It is agreed that tmem can be removed from xen.git. See the thread starting
> >
> >
> > from .
>
>
We now have proper types for all users, we can drop this one.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Pavel Tatashin
Cc: Stephen Rothwell
Cc: Andrew Banman
Cc: "mike.tra...@hpe.com"
Cc: Oscar Salvador
Cc: Dave Hansen
Cc: Michal Hocko
Cc:
The ITS driver was added in Xen 4.10 as a technical preview feature.
However, it is required in order to boot Xen as Thunder-X because
PCI devices don't support legacy interrupt.
So enable CONFIG_ITS in our Xen build.
Signed-off-by: Julien Grall
---
ts-xen-build | 4
1 file changed, 4
> On Nov 30, 2018, at 4:12 PM, George Dunlap wrote:
>
>
>
>> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
>>
>> George Dunlap writes ("[PATCH 7/9] libxl: Make killing of device model
>> asynchronous"):
>>> Or at least, give it an asynchronous interface so that we can make it
>>>
On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> Which, on x86, requires fiddling with the INTx bit in PCI config space,
> since for internally used MSI we can't delegate this to Dom0.
>
> ns16550_init_postirq() also needs (benign) re-ordering of its
> operations.
>
>
Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> It is agreed that tmem can be removed from xen.git. See the thread starting
>
>
> from .
Those are notes from some phone call amongst industry stakeholders.
None
On 11/30/18 6:01 AM, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from
On Fri, 30 Nov 2018 at 09:39, Mao Zhongyi
wrote:
>
> v3 -> v2:
>
> - rebase to the HEAD
> - use SysBusDevice *sbd variable in patch15
> Mao Zhongyi (21):
> musicpal: Convert sysbus init function to realize function
> block/noenand: Convert sysbus init function to realize function
>
GICv2 and GICv3 supports up to 1020 interrupts. However, the value computed
from GICD_TYPER.ITLinesNumber can be up to 1024. On GICv3, we will end up to
write in reserved registers that are right after the IROUTERs one as the
value is not capped early enough.
Cap the number of interrupts as soon
> On Nov 28, 2018, at 4:56 PM, Ian Jackson wrote:
>
>> if (!xs_rm(CTX->xsh, XBT_NULL, path))
>> LOGD(ERROR, domid, "xs_rm failed for %s", path);
>>
>> -/* We should try to destroy the device model anyway. */
>> -rc = kill_device_model(gc,
>> -
For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
supports the instruction, but the guest may have not have rdtscp in its
featureset. Bring the vmexit handlers in line with the main emulator
behaviour by optionally handing back #UD.
Next on the AMD side, if RDTSCP actually
For some reason (on EPYC at least) we've gained a regression into master
whereby VMs are defaulting to one of the emulated TSC modes. This may be Xen
coming to the conclusion that there isn't a reliable TSC. Combined with a
debug Xen, this breaks RDTSCP completely.
With this series in place and
Sadly, a lone:
(XEN) emulate.c:156:d2v0 __get_instruction_length_from_list: Mismatch between
expected and actual instruction: eip = f804564139c0
on the console is of no use trying to identify what went wrong. Dump as much
state as we can to help identify what went wrong.
Reported-by:
On Fri, Nov 30, 2018 at 05:07:19PM +, Andy Cooper wrote:
> Sadly, a lone:
>
> (XEN) emulate.c:156:d2v0 __get_instruction_length_from_list: Mismatch
> between expected and actual instruction: eip = f804564139c0
>
> on the console is of no use trying to identify what went wrong. Dump
Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
functional change.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Martin Schwidefsky
Cc: Heiko
Memory onlining should always be handled by user space, because only user
space knows which use cases it wants to satisfy. E.g. memory might be
onlined to the MOVABLE zone even if it can never be removed from the
system, e.g. to make usage of huge pages more reliable.
However to implement such
Let's introduce new types for different kinds of memory blocks and use
them in existing code. As I don't see an easy way to split this up,
do it in one hunk for now.
acpi:
Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
Properly change the type when trying to add
This is the second approach, introducing more meaningful memory block
types and not changing online behavior in the kernel. It is based on
latest linux-next.
As we found out during dicussion, user space should always handle onlining
of memory, in any case. However in order to make smart decisions
Hi,
Below a list of backport candidate for Arm.
For Xen 4.10+ to handle correctly SMC call parameters and result
35fc608612 xen/arm: smccc-1.1: Make return values unsigned long
fa7974f743 xen/arm: smccc-1.1: Handle function result as parameters
For Xen 4.9+ to avoid Dom0 crash when
flight 130847 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130847/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 130804
Thank you Boris for your comments. I removed faulty email of mine.
replies inline.
On 11/30/2018 12:42 PM, Boris Ostrovsky wrote:
On 11/29/18 12:17 AM, Manjunath Patil wrote:
Hi,
Feel free to suggest/comment on this.
I am trying to do the following at dst during the migration now.
1. Dont
> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
>
> George Dunlap writes ("[PATCH 7/9] libxl: Make killing of device model
> asynchronous"):
>> Or at least, give it an asynchronous interface so that we can make it
>> actually asynchronous in subsequent patches.
>>
>> Create state
Wei Liu writes ("[PATCH v2 1/3] tools: remove tmem code and commands"):
> Remove all tmem related code in libxc.
>
> Leave some stubs in libxl in case anyone has linked to those functions
> before the removal.
>
> Remove all tmem related commands in xl, all tmem related code in other
> utilities
On Fri, 30 Nov 2018, Boris Ostrovsky wrote:
> On 11/30/18 6:01 AM, Wen Yang wrote:
> > The problem is that we call this with a spin lock held.
> > The call tree is:
> > pvcalls_front_accept() holds bedata->socket_lock.
> > -> create_active()
> > -> __get_free_pages() uses GFP_KERNEL
>
Hello Andre,
Please see my comments below:
On 23.11.18 14:18, Andre Przywara wrote:
Fundamentally there is a semantic difference between edge and level
triggered IRQs: When the guest has handled an *edge* IRQ (EOIed so
the LR's state goes to 0), this is done and dusted, and Xen doesn't
need
On 11/29/18 12:17 AM, Manjunath Patil wrote:
> Hi,
> Feel free to suggest/comment on this.
>
> I am trying to do the following at dst during the migration now.
> 1. Dont clear the old rinfo in blkif_free(). Instead just clean it.
> 2. Store the old rinfo and nr_rings into temp variables in
There's a couple fixes for the recent LDT remap placement change.
The first patch fixes crash when kernel booted as Xen dom0.
The second patch fixes address space markers in dump_pagetables output.
It's purely cosmetic change, backporting to the stable tree is optional.
v2:
- Fix typo
Kirill
The LDT remap placement has been changed. It's now placed before direct
mapping in the kernel virtual address space for both paging modes.
Change address markers order accordingly.
Signed-off-by: Kirill A. Shutemov
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
On 11/29/18 3:58 PM, Jan Beulich wrote:
On 29.11.18 at 14:23, wrote:
>> On 11/29/18 12:04 PM, Jan Beulich wrote:
>> On 28.11.18 at 22:56, wrote:
Changes since V9:
- Removed the patch RFC (replaced by a printk(XENLOG_G_WARNING).
- Reused start and end in
Applied to both x86 and ARM headers.
Signed-off-by: Christopher Clark
---
xen/include/asm-arm/guest_access.h | 25 +
xen/include/asm-x86/guest_access.h | 29 +
xen/include/xen/guest_access.h | 3 +++
3 files changed, 57 insertions(+)
A convenience for working on development of the argo subsystem:
toggling a local #define variable turns on just the debug messages
in this subsystem.
printk("argo: " format, ## args )
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 13 +
1 file changed, 13 insertions(+)
On Fri, Nov 30, 2018 at 06:59:20PM +0100, David Hildenbrand wrote:
>Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
>memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
>functional change.
I would suggest to put more words to this.
"
Function
On Fri, Nov 30, 2018 at 06:59:18PM +0100, David Hildenbrand wrote:
>This is the second approach, introducing more meaningful memory block
>types and not changing online behavior in the kernel. It is based on
>latest linux-next.
>
>As we found out during dicussion, user space should always handle
Hi Julien,
These patches fix my Hikey960 problems - I'm able to boot all expected
CPUs without trouble now.
Feel free to add
Tested-by: Matthew Daley
if you want.
Thanks for the good work!
- Matthew
On Fri, 30 Nov 2018 at 00:37, Julien Grall wrote:
>
> Hi all,
>
> This patch series fixes 2
flight 130851 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 130807
build-arm64-pvops
On Fri, Nov 30, 2018 at 06:59:19PM +0100, David Hildenbrand wrote:
>Memory onlining should always be handled by user space, because only user
>space knows which use cases it wants to satisfy. E.g. memory might be
>onlined to the MOVABLE zone even if it can never be removed from the
>system, e.g.
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/xen/pvcalls-front.c: In function 'pvcalls_front_sendmsg':
drivers/xen/pvcalls-front.c:506:25: warning:
variable 'bedata' set but not used [-Wunused-but-set-variable]
drivers/xen/pvcalls-front.c: In function 'pvcalls_front_recvmsg':
Takes a single argument: a handle to the registered ring.
The ring's entry is removed from the hashtable of registered rings;
any entries for pending notifications are removed; and the ring is
unmapped from Xen's address space.
Signed-off-by: Christopher Clark
---
xen/common/argo.c |
Used by a domain to register a region of memory for receiving messages from
either a specified other domain, or, if specifying a wildcard, any domain.
This operation creates a mapping within Xen's private address space that
will remain resident for the lifetime of the ring. In subsequent commits,
Will inhibit initialization of the domain's argo data structure to
prevent receiving any messages or notifications and access to any of
the argo hypercall operations.
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 4 ++--
xen/include/xsm/dummy.h | 5 +
Very basic implementation: a fixed limit of 128.
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index ca48032..cc908f4 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@
XSM hooks implement distinct permissions for these two distinct cases of
Argo ring registration:
* Single source: registering a ring for communication to receive messages
from a specified single other domain.
Default policy: allow.
* Any source: registering a ring for
Initialises basic data structures and performs teardown of argo state
for domain shutdown.
Introduces headers:
with definions of addresses and ring structure, including
indexes for atomic update for communication between domain and hypervisor,
and to support hooking init and destroy into
Signed-off-by: Christopher Clark
---
xen/common/Kconfig | 20
1 file changed, 20 insertions(+)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 68132a3..a06ddcb 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -200,6 +200,26 @@ config LATE_HWDOM
Signed-off-by: Christopher Clark
---
xen/include/public/xen.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 0a27546..8dc032b 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -982,6 +982,8 @@ typedef struct {
sendv operation is invoked to perform a synchronous send of buffers
contained in iovs to a remote domain's registered ring.
It takes:
* A destination address (domid, port) for the ring to send to.
It performs a most-specific match lookup, to allow for wildcard.
* A source address, used to
Needed by a guest to obtain the evtchn port to use, if notifications are via
event channel, so: this operation will return the current notification method
active for the domain, and method-specific configuration data:
* event channel: port number
* VIRQ: virq number
Return structure has
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 0858fb2..39778fd 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -845,6 +845,17 @@ argo_fill_ring_data(struct domain
Presence is gated upon CONFIG_ARGO.
Registers the hypercall previously reserved for this.
Takes 5 arguments, does nothing and returns -ENOSYS.
Will be avoiding a compat ABI by using fixed-size types in hypercall ops.
Signed-off-by: Christopher Clark
---
xen/arch/x86/guest/hypercall_page.S |
arm port of commit bb544585137259545d4adc9afe6eed8dc7c7376d
This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
Signed-off-by: Christopher Clark
---
xen/include/asm-arm/guest_access.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/include/asm-arm/guest_access.h
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
describes these codes thus:
EMSGSIZE : "Message too large"
ECONNREFUSED : "Connection refused".
Signed-off-by: Christopher Clark
---
xen/include/public/errno.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
Default policy: allow.
Signed-off-by: Christopher Clark
---
xen/include/xsm/dummy.h | 5 +
xen/include/xsm/xsm.h | 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 7 +++
xen/xsm/flask/policy/access_vectors | 2 ++
5
Allocates an IPI-bound event channel on vcpu0 for specified domain.
Is able to bypass the existence check on vcpu number since vcpu 0
should always exist. Bypass is required at the point of use by Argo.
Signed-off-by: Christopher Clark
---
xen/common/event_channel.c | 35
Default to disabled.
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 1872d37..82fab36 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -28,6 +28,10 @@
Very basic implementation: a fixed limit of 256.
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index cc908f4..0858fb2 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -27,6 +27,7
This patch series implements the Argo hypervisor-mediated interdomain
communication mechanism as an experimental feature for incorporation
into the Xen hypervisor.
Relevant to the ARM deadline for inclusion in the Xen 4.12 release,
there are very few and only minor ARM-specific changes in this
so that the guest may re-register the rings on resume with current mappings.
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 69 ++
xen/common/domain.c| 9 +++
xen/include/xen/argo.h | 2 ++
3 files changed, 80
* x86 PV domains are notified via event channel.
PV guests are known to have the event channel software present in the guest
kernel, so it is fine to depend on and use it.
* x86 HVM domains and all ARM domains are notified via VIRQ.
The intent is to remove the requirement for event channel
This is out of an abundance of caution, since this is a very basic hash
function, chosen more for its bucket distribution properties to cluster related
rings rather than for cryptographic strength or any uniformness of output,
and it operates upon values supplied by the guest just before being
Queries for data about space availability in registered rings and
causes notification to be sent when space has become available.
The hypercall op populates a supplied data structure with information about
ring state, and if insufficent space is currently available in a given ring,
the hypervisor
To be used by Argo for delivery of notifications to some guests.
Signed-off-by: Christopher Clark
---
xen/common/event_channel.c | 2 +-
xen/include/xen/event.h| 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
flight 130853 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130853/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 130787
flight 130854 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676
Tests which
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I removed faulty email of mine.
>
> replies inline.
> On 11/30/2018 12:42 PM, Boris Ostrovsky wrote:
>> On 11/29/18 12:17 AM, Manjunath Patil wrote:
>>> Hi,
>>> Feel free to suggest/comment on this.
>>>
>>> I am
>>> On 29.11.18 at 18:44, wrote:
> On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
>> --- a/xen/arch/x86/efi/Makefile
>> +++ b/xen/arch/x86/efi/Makefile
>> @@ -5,7 +5,11 @@ CFLAGS += -fshort-wchar
>>
>> boot.init.o: buildid.o
>>
>> +EFIOBJ := boot.init.o compat.o runtime.o
>> +
>>> On 29.11.18 at 20:20, wrote:
> In almost all cases, Xen and libxc will agree on the featureset length,
> because they are built from the same source.
>
> However, there are circumstances (e.g. security hotfixes) where the featureset
> gets longer and dom0 will, after installing updates, be
At 07:53 -0700 on 29 Nov (1543477992), Jan Beulich wrote:
> We've had more than one report of host crashes after failed migration,
> and in at least one case we've had a hint towards a too far shrunk
> shadow allocation pool. Instead of just checking the pool for being
> empty, check whether the
flight 130842 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
130373
>>> On 29.11.18 at 20:20, wrote:
> get_cpuid_domain_info() has two conflicting return styles - either -error for
> local failures, or -1/errno for hypercall failures. Switch to consistently
> use -error.
>
> While fixing the xc_get_cpu_featureset(), take the opportunity to remove the
>
>>> On 30.11.18 at 09:57, wrote:
> On Thu, Nov 29, 2018 at 10:46:05AM +0100, Roger Pau Monné wrote:
>>On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
>>> It is better that all CPUs have the same microcode revision.
>>>
>>> Linux kernel rejects late microcode update if finding some
>>> On 29.11.18 at 23:43, wrote:
> One other comment about this patch (which IIRC was raised by Andrew on
> an earlier version) is that it may be worth to stop timer calibration. I
> am pretty sure we've seen deadlocks, which is why we ended up disabling
> it during microcode updates.
I recall
On Thu, Nov 29, 2018 at 10:56:53AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:16PM +0800, Chao Gao wrote:
>> >> This patch ports microcode improvement
flight 130840 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 130142
>>> On 30.11.18 at 08:55, wrote:
> On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
>>On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
>>> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>>> >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>>>
The init function doesn't do anything at all, so we
just omit it.
Cc: sstabell...@kernel.org
Cc: anthony.per...@citrix.com
Cc: xen-devel@lists.xenproject.org
Cc: peter.mayd...@linaro.org
Signed-off-by: Mao Zhongyi
Signed-off-by: Zhang Shengju
Acked-by: Anthony PERARD
---
hw/xen/xen_backend.c
v3 -> v2:
- rebase to the HEAD
- use SysBusDevice *sbd variable in patch15
v2 -> v1:
- SYS_BUS_DEVICE(dev) was used in a function several
times, so use a variable 'sbd' to replace it, like:
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
- remove the xen_sysdev_init() function
- drop the patch21
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and, instead, adds explicit flushing at the
end of the loops in the iommu_map/unmap() wrapper functions.
Because VT-d currently performs two different types of flush dependent upon
whether a PTE
Paul Durrant (2):
amd-iommu: add flush iommu_ops
iommu: elide flushing for higher order map/unmap operations
xen/drivers/passthrough/amd/iommu_map.c | 114 --
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +
xen/drivers/passthrough/arm/smmu.c|
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
>>> On 29.11.18 at 18:33, wrote:
> On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
>>
>> *desc = entry;
>> /* Restore the original MSI enabled bits */
On Thu, Nov 29, 2018 at 10:46:05AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:02:25PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
>> >> diff --git a/xen/arch/x86/microcode.c
On Fri, Nov 30, 2018 at 01:52:39AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 18:33, wrote:
> > On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> >> --- a/xen/arch/x86/msi.c
> >> +++ b/xen/arch/x86/msi.c
> >> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
> >>
>
>>> On 29.11.18 at 18:11, wrote:
> This errata affect the values read from the BAR registers, and could
> render vPCI (and by extension PVH Dom0 unusable).
>
> HSE43 is a Haswell erratum where a non-BAR register is implemented at
> the position where the first BAR of the device should be found
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The
> On Nov 23, 2018, at 5:14 PM, George Dunlap wrote:
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e498435e16..a370de54ed 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1135,6 +1135,8 @@ typedef struct {
> const
On 30/11/2018 10:45, Paul Durrant wrote:
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and, instead, adds explicit flushing at the
> end of the loops in the iommu_map/unmap() wrapper functions.
>
> Because VT-d currently performs two
flight 75627 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-jessie-netboot-pvgrub 10 debian-di-install fail REGR. vs.
75618
Tests
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The
On 30/11/2018 12:01, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from
flight 130849 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130849/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd b1f31943cb61465b80f786de48501e2fb03e1b61
baseline version:
freebsd
1 - 100 of 139 matches
Mail list logo
