* Andy Lutomirski wrote:
> The kernel has several code paths that read CR3. Most of them assume that
> CR3 contains the PGD's physical address, whereas some of them awkwardly
> use PHYSICAL_PAGE_MASK to mask off low bits.
>
> Add explicit mask macros for CR3 and convert all of the CR3 readers.
flight 110380 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110380/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 5 xen-install fail in 110346 pass in 110380
test-amd64-i386-xl-qemuu-win7-amd
On 02/06/17 21:31, Stefano Stabellini wrote:
> Allocate a socket. Keep track of socket <-> ring mappings with a new data
> structure, called sock_mapping. Implement the connect command by calling
> inet_stream_connect, and mapping the new indexes page and data ring.
> Allocate a workqueue and a wor
On 02/06/17 21:31, Stefano Stabellini wrote:
> Just reply with success to the other end for now. Delay the allocation
> of the actual socket to bind and/or connect.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/pvcalls-back.c | 2
On 02/06/17 21:31, Stefano Stabellini wrote:
> Also add pvcalls-back to the Makefile.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/Kconfig | 12
> drivers/xen/Makefile | 1 +
> 2 files changed, 13 insertions(+)
>
flight 110383 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110383/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 108165
test-amd64-i386-xl-qemuu-win7-amd64 16 g
On 3/29/2017 5:30 AM, Goel, Sameer wrote:
Sure, I will try to post something soon.
Hi Sameer,
Are you still working on SMMU v3, can you please post patches.
Thanks
Manish
Thanks,
Sameer
On 3/27/2017 11:03 PM, Vijay Kilari wrote:
On Mon, Mar 27, 2017 at 10:00 PM, Goel, Sameer wrote:
Hi,
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-vhd
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Foun
flight 110371 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
flight 110374 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
110219
Tests whi
This fixes the python bindings, since symbols were missing in libxenstat.
xentop doesn't use any yajl functions, so drop linking libyajl.
Signed-off-by: Peter Große
---
tools/xenstat/libxenstat/Makefile | 2 +-
tools/xenstat/xentop/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletio
Signed-off-by: Peter Große
---
tools/xenstat/libxenstat/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstat/libxenstat/Makefile
b/tools/xenstat/libxenstat/Makefile
index 85cec63ebf..08b0f35172 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenst
Hello.
I tried to build and use the python bindings for libxenstat.
Building worked, after I changed the hardcoded PYTHON_VERSION variable in the
tools/xenstat/libxenstat/Makefile. Maybe the version detected by configure
can be used here. The 1st patch tries to address this.
Then, when I tried t
On Fri, 9 Jun 2017, Andre Przywara wrote:
> For LPIs the struct pending_irq's are dynamically allocated and the
> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
> at any time, teach the VGIC how to deal with irq_to_pending() returning
> a NULL pointer.
> We just do nothing
On Mon, 12 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 09/06/17 18:41, Andre Przywara wrote:
> > @@ -285,6 +291,17 @@ void arch_move_irqs(struct vcpu *v)
> > struct vcpu *v_target;
> > int i;
> >
> > +/*
> > + * We don't migrate LPIs at the moment.
> > + * If we ever do
On Mon, 12 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 09/06/17 18:41, Andre Przywara wrote:
> > When reading the priority value of a virtual interrupt, we were taking
> > the respective rank lock so far.
> > However for forwarded interrupts (Dom0 only so far) this may lead to a
> > deadlock
Hi all,
I think we should discuss and agree on a set of tags to use in our
backports to stable trees.
Specifically, I would like to see a tag that specifies the id of the
original commit, like "master commit" that Jan is using today. I would
prefer if the tag didn't have any spaces, thus, I sugge
> +
> static void pvcalls_back_work(struct work_struct *work)
> {
> + struct pvcalls_fedata *priv = container_of(work,
> + struct pvcalls_fedata, register_work);
> + int notify, notify_all = 0, more = 1;
> + struct xen_pvcalls_request req;
> + struct xenbus_device *de
On Mon, 2017-06-12 at 13:01 -0400, Boris Ostrovsky wrote:
> On 06/12/2017 04:08 AM, Jan Beulich wrote:
> > > > > On 19.05.17 at 17:50, wrote:
> > >
> > > Instead of scrubbing pages during guest destruction (from
> > > free_heap_pages()) do this opportunistically, from the idle loop.
> >
> > This
On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce a per-frontend data structure named pvcalls_fedata. It
> contains pointers to the command ring, its event channel, a list of
> active sockets and a tree of passive sockets (passing sockets need to be
> looked up from the id on listen, ac
On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce the code to handle xenbus state changes.
>
> Implement the probe function for the pvcalls backend. Write the
> supported versions, max-page-order and function-calls nodes to xenstore,
> as required by the protocol.
>
> Introduce stub fun
On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce the C header file which defines the PV Calls interface. It is
> imported from xen/include/public/io/pvcalls.h.
>
> Signed-off-by: Stefano Stabellini
> CC: konrad.w...@oracle.com
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Re
flight 110362 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110362/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail
in 110311 pass in 110362
test-a
flight 110369 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 5 kernel-build fail REGR. vs. 110131
test-amd64-i386-xl-q
flight 110353 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-buildfail REGR. vs. 109620
build-i386-xsm
Hi Ian,
Thanks for pointing out the problems. I've consulted several
maintainers about this
and have drafted a new patch for it (in a new [patch v2] thread).
Please have a look
at it. Thanks.
Cheers,
Zhongze Liu.
2017-06-12 20:31 GMT+08:00 Ian Jackson :
> Zhongze Liu writes ("[PATCH] tools: fix
GCC 7.1.1 complains that several buffers passed to snprintf() in xenpmd
and tools/ocmal/xc are too small to hold the largest possible resulting string.
enlarge the size of these buffers to fix the warnings.
Signed-off-by: Zhongze Liu
---
CC: David Scott
CC: Ian Jackson
CC: Wei Liu
Changed si
On Mon, Jun 12, 2017 at 04:51:48PM +0100, Wei Liu wrote:
> On Fri, Jun 09, 2017 at 07:51:54PM +0300, Adrian Pop wrote:
> > Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> > privileged domain to change the value of the #VE suppress bit for a
> > page.
> >
> > Add a libxc wrapp
The kernel has several code paths that read CR3. Most of them assume that
CR3 contains the PGD's physical address, whereas some of them awkwardly
use PHYSICAL_PAGE_MASK to mask off low bits.
Add explicit mask macros for CR3 and convert all of the CR3 readers.
This will keep them from breaking whe
flight 110346 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110346/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 110093
test-amd64-i386-xl-
>> @@ -1175,6 +1258,8 @@ static void free_heap_pages(
>> if ( page_state_is(&pg[i], offlined) )
>> tainted = 1;
>>
>> +pg[i].u.free.scrub_state = 0;
> Is this really needed for every page in the buddy?
>
The concern here is that is we break the buddy (in alloc_heap
On 06/12/2017 04:08 AM, Jan Beulich wrote:
On 19.05.17 at 17:50, wrote:
>> Instead of scrubbing pages during guest destruction (from
>> free_heap_pages()) do this opportunistically, from the idle loop.
> This is too brief for my taste. In particular the re-ordering ...
>
>> --- a/xen/arch/x86
Hi Jan,
On 12/06/17 16:27, Jan Beulich wrote:
On 12.06.17 at 17:11, wrote:
We place the trampoline no lower than at 256k, so we have ample space
to read the MBRs of BIOS disks into an aligned buffer right below the
trampoline (not doing so has been found to be a problem on a buggy BIOS
coming
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> I have not imported augmented and rcu rbtree functionality to the xen
> tree,
> as there was no specific requirement for current planned
> implementation.
>
> Please share your inputs. Thanks in advance.
>
So, I'm having another look at th
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> Empty nodes have no color. We can make use of this property to
> simplify the
> code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE macros.
>
Mmm... you have significantly cut the changelog. I appreciate that some
of the removed text speak
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> --- a/xen/common/rbtree.c
> +++ b/xen/common/rbtree.c
> @@ -110,11 +110,8 @@ void rb_insert_color(struct rb_node *node,
> struct rb_root *root)
>
> if (parent->rb_right == node)
> {
> -register str
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just
iterate over all mapped LPIs and filter
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in our virtual ITTE and the pending_irq.
Signed-off-by: And
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts. MAPI is just a variant
of this comment, where the LPI ID is the same as the event ID.
We connect the already allocated host LPI t
Hi Andre,
On 07/06/17 18:49, Andre Przywara wrote:
On 02/06/17 18:12, Julien Grall wrote:
On 05/26/2017 06:35 PM, Andre Przywara wrote:
+/*
+ * radix_tree_insert() returns an error either due to an internal
+ * condition (like memory allocation failure) or because the LPI
already
+
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
@@ -478,8 +515,14 @@ static void gic_update_one_lr(struct vcpu *v, int i)
gic_hw_ops->read_lr(i, &lr_val);
irq = lr_val.virq;
p = irq_to_pending(v, irq);
-/* An LPI might have been unmapped, in which case we just clean up here
Hi,
On 08/06/17 15:03, Juergen Gross wrote:
> There has been a report about a deadlock in the xenbus driver:
>
> [ 247.979498] ==
> [ 247.985688] WARNING: possible circular locking dependency detected
> [ 247.991882] 4.12.0-rc4-00022-gc4b25c0
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> --- a/xen/common/rbtree.c
> +++ b/xen/common/rbtree.c
> @@ -376,18 +376,29 @@ static void __rb_erase_color(struct rb_node
> *node, struct rb_node *parent,
>
> void rb_erase(struct rb_node *node, struct rb_root *root)
> {
> -struct rb
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.
Hmm
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> @@ -65,6 +65,22 @@ static inline struct rb_node *rb_red_parent(struct
> rb_node *red)
> return (struct rb_node *)red->__rb_parent_color;
> }
>
> +static inline void
> +__rb_change_child(struct rb_node *old, struct rb_node *new,
> +
Hi,
On 09/06/17 20:14, Stefano Stabellini wrote:
> On Fri, 9 Jun 2017, Andre Przywara wrote:
>> On 02/06/17 18:12, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 05/26/2017 06:35 PM, Andre Przywara wrote:
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actuall
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on a
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusin
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if there is at least one ITS emulated
for that guest (whi
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index dbaf45a..03d23b6 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -136,6 +136,85 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool
use_p
On Fri, Jun 09, 2017 at 07:47:12AM -0600, Jan Beulich wrote:
> Avoid needless gaps. Make flags field mandatory for all three
> operations (and rename it to fit the intended future purpose of
> possibly holding more than just one flag).
>
> Also correct a typo in a related domctl.h comment.
>
> Si
On Fri, Jun 09, 2017 at 07:51:54PM +0300, Adrian Pop wrote:
> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> privileged domain to change the value of the #VE suppress bit for a
> page.
>
> Add a libxc wrapper for invoking this hvmop.
>
> Signed-off-by: Adrian Pop
> ---
>
flight 110375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110375/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
To get easy access to the VCPU a forwareded LPI interrupt should be
NIT: s/forwareded/forwarded/
injected to, so far we stored the VCPU ID in the host LPI entry.
However this creates a redundancy, since we keep the target VCPU in
the struct
I've just noticed I had forgotten to update the version of the patch in
the email subject. Sorry!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
We enhance struct pending_irq to cache the priority information
for LPIs. Reading the information from there is faster than accessing
the property table from guest memory. Also it use some padding area in
the struct, so does not require more mem
>>> On 12.06.17 at 17:19, wrote:
> On 12/06/17 11:55, Jan Beulich wrote:
> On 12.06.17 at 12:24, wrote:
>>> I am trying to understand why we decided to implement the helpers
>>> read_atomic, write_atomic, add_sized in assembly rather than directly in C.
>>>
>>> AFAICT implementation in C sim
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to clean it up and re-initialize it later on.
Export vgic_init_pending_irq() and extend it to be reusable.
Si
On 12/06/17 16:11, Jan Beulich wrote:
> We place the trampoline no lower than at 256k, so we have ample space
> to read the MBRs of BIOS disks into an aligned buffer right below the
> trampoline (not doing so has been found to be a problem on a buggy BIOS
> coming with a Skull Canyon NUC). To facil
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothin
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
To avoid code duplication in a later patch, introduce a generic function
to remove a virtual IRQ from the VGIC.
Call that function instead of the open-coded version in vgic_migrate_irq().
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c
>>> On 12.06.17 at 17:11, wrote:
> We place the trampoline no lower than at 256k, so we have ample space
> to read the MBRs of BIOS disks into an aligned buffer right below the
> trampoline (not doing so has been found to be a problem on a buggy BIOS
> coming with a Skull Canyon NUC). To facilitat
I wrote on IRC:
11:07 andyhhp: Looking at your xtf failure in 110095.
11:08 Diziet: yes - it is odd
11:08 the test itself didn't fail
11:10 andyhhp: Jun 8 07:26:08 osstest uptime: 07:26:08 up 168
days, 19:53, 9 users, load average: 19.87, 10.37, 9.17
11:10 So your failure coi
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
@@ -285,6 +291,17 @@ void arch_move_irqs(struct vcpu *v)
struct vcpu *v_target;
int i;
+/*
+ * We don't migrate LPIs at the moment.
+ * If we ever do, we must make sure that the struct pending_irq does
+ * not go away,
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 June 2017 16:08
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel(xen-
> de...@lists.xenproject.org) ; 'Boris
> Ostrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel] d
>>> On 12.06.17 at 17:03, wrote:
> On 12/06/17 15:06, Jan Beulich wrote:
> On 12.06.17 at 14:41, wrote:
>>> On 12/06/17 07:23, Jan Beulich wrote:
As a side note, I'm removing these here since the further
SIMD emulation patches I have ready, but would prefer to
post only once 4.
Hi,
On 12/06/17 11:55, Jan Beulich wrote:
On 12.06.17 at 12:24, wrote:
>> I am trying to understand why we decided to implement the helpers
>> read_atomic, write_atomic, add_sized in assembly rather than directly in C.
>>
>> AFAICT implementation in C similar to Linux helpers WRITE_ONCE/REA
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The function name gic_remove_from_queues() was a bit of a misnomer,
since it just removes an IRQ from the pending queue, not both queues.
Rename the function to make this more clear, also give it a pointer to
a struct pending_irq directly and re
We place the trampoline no lower than at 256k, so we have ample space
to read the MBRs of BIOS disks into an aligned buffer right below the
trampoline (not doing so has been found to be a problem on a buggy BIOS
coming with a Skull Canyon NUC). To facilitate that move MBR reading
past EDD info retr
>>> On 12.06.17 at 16:43, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Paul Durrant
>> Sent: 12 June 2017 15:29
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 12 June 2017 14:55
>> > >> > That worked fine:
>> > >> >
>> > >> > (XEN) MBR[80] @ 85e0
To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7.
The only patch we have applies cleanly.
Reported-by: Zhongze Liu
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Zhongze Liu
---
tools/firmware/etherboot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On 12/06/17 15:06, Jan Beulich wrote:
On 12.06.17 at 14:41, wrote:
>> On 12/06/17 07:23, Jan Beulich wrote:
>> On 09.06.17 at 19:50, wrote:
On 08/06/17 16:49, Jan Beulich wrote:
> Drop a redundant input constraint, correct a comment, and (re)move
> fix.insn_bytes adjustments
> -Original Message-
> From: Paul Durrant
> Sent: 12 June 2017 15:43
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: Juergen Gross ; Andrew Cooper
> ; Julien Grall (julien.gr...@arm.com)
> ; 'Boris Ostrovsky' ;
> xen-devel(xen-de...@lists.xenproject.org) de...@lists.xenproject.org>
> Subject:
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).
DomUs get the legacy number of 1
>>> On 12.06.17 at 16:30, wrote:
> On 09/06/17 09:19, Jan Beulich wrote:
> On 07.06.17 at 10:12, wrote:
>> On 06.06.17 at 21:19, wrote:
On Tue, 6 Jun 2017, Jan Beulich wrote:
On 06.06.17 at 16:00, wrote:
>> Looking at the serial logs for that and comparing them with 10
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
Even though the ITS emulation is not yet in place, the host ITS already
gets initialized and Xen tries to map the host collections.
However for commands to be processed we need to *enable* the ITS, which
will be done in a later patch not yet mer
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IR
flight 110340 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110340/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 guest-start fail REGR. vs. 109975
test-amd64-amd64-
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 12 June 2017 15:29
> To: 'Jan Beulich'
> Cc: Juergen Gross ; Andrew Cooper
> ; Julien Grall (julien.gr...@arm.com)
> ; 'Boris Ostrovsky' ;
> xen-devel(xen-de...@lists.xenproj
Hi Jan,
On 09/06/17 09:19, Jan Beulich wrote:
On 07.06.17 at 10:12, wrote:
On 06.06.17 at 21:19, wrote:
On Tue, 6 Jun 2017, Jan Beulich wrote:
On 06.06.17 at 16:00, wrote:
Looking at the serial logs for that and comparing them with 10009,
it's not terribly easy to see what's going on beca
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 June 2017 14:55
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel(xen-
> de...@lists.xenproject.org) ; 'Boris
> Ostrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel] d
On 09/06/17 14:47, Jan Beulich wrote:
Avoid needless gaps. Make flags field mandatory for all three
operations (and rename it to fit the intended future purpose of
possibly holding more than just one flag).
Also correct a typo in a related domctl.h comment.
Signed-off-by: Jan Beulich
---
The
Currently there is no reliable user interface inside a Xen guest to
determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
try to determine this by various rather hacky mechanisms (parsing of
boot messages before they are gone, trying to make use of known subtle
differences in behav
Today only a few sysfs nodes under /sys/hypervisor/ are documented
for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu.
Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new
file Documentation/ABI/stable/sysfs-hypervisor-xen and add the Xen
specific sysfs docs to the MAINTAINERS
For support of Xen hypervisor live patching the hypervisor build id is
needed. Add a node /sys/hypervisor/properties/buildid containing the
information.
Signed-off-by: Juergen Gross
---
Documentation/ABI/testing/sysfs-hypervisor-xen | 11 +-
drivers/xen/sys-hypervisor.c
Sync include/xen/interface/version.h with the Xen source.
Signed-off-by: Juergen Gross
---
include/xen/interface/version.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
index 7ff6498679a3..145f12f9ecec 10064
In order to be able to determine the Xen guest type from within the
guest as a user there is currently no stable interface available.
Add a sysfs node for that purpose as the guest type information is
available for the kernel.
While doing this document all the other Xen related sysfs nodes.
Add
>>> On 12.06.17 at 16:02, wrote:
> My original statement was "if the guest uses LBR/LER, then migration
> needs to be restricted to hardware with an identical LBR format".
>
> You countered that, saying we could emulate LBR/LER as an alternative.
> The implication here is that we could alter the
Hi Jan,
On 09/06/17 14:47, Jan Beulich wrote:
Avoid needless gaps. Make flags field mandatory for all three
operations (and rename it to fit the intended future purpose of
possibly holding more than just one flag).
Also correct a typo in a related domctl.h comment.
Signed-off-by: Jan Beulich
>>> On 12.06.17 at 14:41, wrote:
> On 12/06/17 07:23, Jan Beulich wrote:
> On 09.06.17 at 19:50, wrote:
>>> On 08/06/17 16:49, Jan Beulich wrote:
Drop a redundant input constraint, correct a comment, and (re)move
fix.insn_bytes adjustments (these aren't needed for custom stub
i
On 12/06/17 14:42, Jan Beulich wrote:
On 12.06.17 at 15:36, wrote:
>> On 12/06/17 14:29, Jan Beulich wrote:
>> On 12.06.17 at 15:07, wrote:
On 08/06/17 14:47, Jan Beulich wrote:
On 08.06.17 at 15:12, wrote:
>> The `disable_migrate` field shall be dropped. The concept
>>> On 12.06.17 at 14:05, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 12 June 2017 12:12
>> To: Paul Durrant
>> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
>> Cooper ; xen-devel(xen-
>> de...@lists.xenproject.org) ; 'Boris
>> Ostrovsky' ; Ju
This run is configured for baseline tests only.
flight 71545 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71545/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-ins
>>> On 12.06.17 at 15:36, wrote:
> On 09/06/17 12:15, Robin Murphy wrote:
>> On 08/06/17 20:30, Sameer Goel wrote:
>> [...]
>>> /**
>>> - * iort_iommu_configure - Set-up IOMMU configuration for a device.
>>> + * iort_iommu_configure - Set-up IOMMU configuration for a device. This
>>> + * function
>>> On 12.06.17 at 15:36, wrote:
> On 12/06/17 14:29, Jan Beulich wrote:
> On 12.06.17 at 15:07, wrote:
>>> On 08/06/17 14:47, Jan Beulich wrote:
>>> On 08.06.17 at 15:12, wrote:
> The `disable_migrate` field shall be dropped. The concept of
> migrateability
> is not boolea
Use substep_eval, so we cope with xen.git revisions which do not
support `make dist-tests'.
Signed-off-by: Ian Jackson
---
ts-xen-build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ts-xen-build b/ts-xen-build
index eaf44b1..097ac0a 100755
--- a/ts-xen-build
+++ b/ts-xen
(CC x86 folks)
Hi,
On 09/06/17 12:15, Robin Murphy wrote:
On 08/06/17 20:30, Sameer Goel wrote:
[...]
/**
- * iort_iommu_configure - Set-up IOMMU configuration for a device.
+ * iort_iommu_configure - Set-up IOMMU configuration for a device. This
+ * function sets up the fwspec as needed for
On 12/06/17 14:29, Jan Beulich wrote:
On 12.06.17 at 15:07, wrote:
>> On 08/06/17 14:47, Jan Beulich wrote:
>> On 08.06.17 at 15:12, wrote:
The `disable_migrate` field shall be dropped. The concept of
migrateability
is not boolean; it is a large spectrum, all of which ne
Wei Liu writes ("[OSSTEST PATCH] Drop build-*-oldkern"):
> That is for testing the in-xen.git kernel build machinery which we
> surely don't care about anymore.
Thanks. I will push this in a moment.
Acked-by: Ian Jackson
Wei Liu writes ("Re: [OSSTEST PATCH] Drop build-*-oldkern"):
> And the ru
1 - 100 of 167 matches
Mail list logo
