>>> On 01.06.17 at 05:18, wrote:
> On 17-05-31 03:36:43, Jan Beulich wrote:
>> >>> On 03.05.17 at 10:44, wrote:
>> > +static void cat_init_feature(const struct cpuid_leaf *regs,
>> > + struct feat_node *feat,
>> > + struct psr_socket_info *i
flight 109915 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109915/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8bef878beada6400aaed2f3c2bf73d6c90cde931
baseline version:
ovmf 4fc8277133fb011d028b4
flight 109889 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 109656
test-amd64-i386-lib
On 17-05-31 03:36:43, Jan Beulich wrote:
> >>> On 03.05.17 at 10:44, wrote:
> > +static void cat_init_feature(const struct cpuid_leaf *regs,
> > + struct feat_node *feat,
> > + struct psr_socket_info *info,
> > + e
On 17-05-31 02:10:27, Jan Beulich wrote:
> >>> On 31.05.17 at 10:05, wrote:
> > On 17-05-31 01:45:45, Jan Beulich wrote:
> >> >>> On 31.05.17 at 09:30, wrote:
> >> > On 17-05-30 08:05:02, Jan Beulich wrote:
> >> >> >>> On 03.05.17 at 10:44, wrote:
> >> >>
> >> >> > --- a/xen/arch/x86/psr.c
> >>
On 2017-05-31 00:37, Steven Haigh wrote:
On 31/05/17 00:18, Boris Ostrovsky wrote:
On 05/30/2017 06:27 AM, Steven Haigh wrote:
Just wanted to give this a nudge to try and get some suggestions on
where to go / what to do about this.
On 28/05/17 09:44, Steven Haigh wrote:
The last couple of day
> From: Han, Huaitong
> Sent: Wednesday, May 31, 2017 4:15 PM
>
> On Wed, 2017-05-31 at 08:44 +0100, Andrew Cooper wrote:
> > On 31/05/2017 08:09, Han, Huaitong wrote:
> > > On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote:
> > >> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com]
> Sent: Tuesday, May 30, 2017 10:05 PM
>
> Occasionally, on certain Broadwell CPUs MSR_IA32_LASTINTTOIP has been
> observed to have the top three bits corrupted as though the MSR is using
> the LBR_FORMAT_EIP_FLAGS_TSX format. This is incor
flight 109882 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-stop fail REGR. vs.
109793
Tests which did
On 31/05/2017 23:40, Dario Faggioli wrote:
> On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
>> First, move some code around in order to make the next change more
>> obvious.
>>
>> commit 16c047add3ceaf0ab882e3e094d1ec904d02312d from linux tree
>>
>> Signed-off-by: Praveen Kumar
>>
> Mmm..
flight 109878 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109878/
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
test-amd64-i386-xl-qe
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> First, move some code around in order to make the next change more
> obvious.
>
> commit 16c047add3ceaf0ab882e3e094d1ec904d02312d from linux tree
>
> Signed-off-by: Praveen Kumar
>
Mmm... actually, I am not absolutely sure of what's the f
On Thu, 2017-06-01 at 02:50 +0530, Praveen Kumar wrote:
> Hi All,
>
Hi,
> The patch imports the changes and updates of the rbtree
> implementaiton
> from Linux tree.
>
Thanks Praveen for doing this.
This series is much better than the previous single and giant patch.
:-)
> But since, the only
flight 109912 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109912/
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
An interesting observation for rb_erase() is that when a node has
exactly one child, the node must be black and the child must be red.
An interesting consequence is that removing such a node can be done by
simply replacing it with its child and making the child black,
which we can do efficiently in
In rb_erase, move the easy case (node to erase has no more than
1 child) first. I feel the code reads easier that way.
commit 60670b8034d6e2ba860af79c9379b7788d09db73 from Linux tree
Signed-off-by: Praveen Kumar
---
xen/common/rbtree.c | 36 ++--
1 file changed,
Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field f
Postorder iteration yields all of a node's children prior to yielding the
node itself, and this particular implementation also avoids examining the
leaf links in a node after that node has been yielded.
In what I expect will be its most common usage, postorder iteration allows
the deletion of ever
In __rb_erase_color(), we often already have pointers to the nodes being
rotated and/or know what their colors must be, so we can generate more
efficient code than the generic __rb_rotate_left() and __rb_rotate_right()
functions.
Also when the current node is red or when flipping the sibling's col
Add __rb_change_child() as an inline helper function to replace code that
would otherwise be duplicated 4 times in the source.
No changes to binary size or speed.
commit 7abc704ae399fcb9c51ca200b0456f8a975a8011 from Linux tree
Signed-off-by: Praveen Kumar
---
xen/common/rbtree.c | 54 +
When looking to fetch a node's sibling, we went through a sequence of:
- check if node is the parent's left child
- if it is, then fetch the parent's right child
This can be replaced with:
- fetch the parent's right child as an assumed sibling
- check that node is NOT the fetched child
This avoid
In __rb_erase_color(), we were always setting a node to black after
exiting the main loop. And in one case, after fixing up the tree to
satisfy all rbtree invariants, we were setting the current node to root
just to guarantee a loop exit, at which point the root would be set to
black. However thi
In __rb_erase_color(), we have to select one of 3 cases depending on the
color on the 'other' node children. If both children are black, we flip a
few node colors and iterate. Otherwise, we do either one or two tree
rotations, depending on the color of the 'other' child opposite to 'node',
and th
- Use the newly introduced rb_set_parent_color() function to flip the color
of nodes whose parent is already known.
- Optimize rb_parent() when the node is known to be red - there is no need
to mask out the color in that case.
- Flipping gparent's color to red requires us to fetch its rb_parent
There are two cases when a node, having 2 childs, is erased:
'normal case': the successor is not the right-hand-child of the node to be
erased
'special case': the successor is the right-hand child of the node to be
erased
Here some ascii-art, with following symbols (referring to the code):
O: node
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.
commit 4c199a93a2d36b277a9fd209a0f2793f8460a215 from linux tree.
Signed-off-by: Praveen Kumar
---
xen/common/rbtree.c | 4 ++--
xen/include/xen/rbtree.h
It is a well known property of rbtrees that insertion never requires more
than two tree rotations. In our implementation, after one loop iteration
identified one or two necessary tree rotations, we would iterate and look
for more. However at that point the node's parent would always be black,
whi
The root node of an rbtree must always be black. However,
rb_insert_color() only needs to maintain this invariant when it has been
broken - that is, when it exits the loop due to the current (red) node
being the root. In all other cases (exiting after tree rotations, or
exiting due to an existing
rbtree users must use the documented APIs to manipulate the tree
structure. Low-level helpers to manipulate node colors and parenthood are
not part of that API, so move them to lib/rbtree.c
commit bf7ad8eeab995710c766df49c9c69a8592ca0216 from linux tree
Signed-off-by: Praveen Kumar
---
xen/com
Furthermore, notice that the initial checks:
if (!node->rb_left)
child = node->rb_right;
else if (!node->rb_right)
child = node->rb_left;
else
{
...
}
guarantee that old->rb_righ
First, move some code around in order to make the next change more obvious.
commit 16c047add3ceaf0ab882e3e094d1ec904d02312d from linux tree
Signed-off-by: Praveen Kumar
---
xen/common/rbtree.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/xen/common/rb
Hi All,
The patch imports the changes and updates of the rbtree implementaiton
from Linux tree. But since, the only current implementation is with tmem.c,
which am not much aware off much and therefore, was unable to test the changes
thoroughly. Having said that, I do have plans of adding futher c
Hi All,
Sorry, I mistakenly sent the patch to Linux kernel developers. Please
ignore the series of patch sent by me.
Will be re-sending the updated patch to respective maintainers.
Sorry once again for spamming your mailbox.
Regards,
~Praveen.
On Thu, Jun 1, 2017 at 2:17 AM, Praveen Kumar
w
flight 109906 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109906/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 8ebc31bc85546a265aa0dbd26fda88b9b195fa2e
baseline version:
xtf d1a237abf651f181e6b11f
When looking to fetch a node's sibling, we went through a sequence of:
- check if node is the parent's left child
- if it is, then fetch the parent's right child
This can be replaced with:
- fetch the parent's right child as an assumed sibling
- check that node is NOT the fetched child
This avoid
Add __rb_change_child() as an inline helper function to replace code that
would otherwise be duplicated 4 times in the source.
No changes to binary size or speed.
commit 7abc704ae399fcb9c51ca200b0456f8a975a8011 from Linux tree
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
Cc: Pete
In rb_erase, move the easy case (node to erase has no more than
1 child) first. I feel the code reads easier that way.
commit 60670b8034d6e2ba860af79c9379b7788d09db73 from Linux tree
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: David W
An interesting observation for rb_erase() is that when a node has
exactly one child, the node must be black and the child must be red.
An interesting consequence is that removing such a node can be done by
simply replacing it with its child and making the child black,
which we can do efficiently in
In __rb_erase_color(), we often already have pointers to the nodes being
rotated and/or know what their colors must be, so we can generate more
efficient code than the generic __rb_rotate_left() and __rb_rotate_right()
functions.
Also when the current node is red or when flipping the sibling's col
In __rb_erase_color(), we have to select one of 3 cases depending on the
color on the 'other' node children. If both children are black, we flip a
few node colors and iterate. Otherwise, we do either one or two tree
rotations, depending on the color of the 'other' child opposite to 'node',
and th
In __rb_erase_color(), we were always setting a node to black after
exiting the main loop. And in one case, after fixing up the tree to
satisfy all rbtree invariants, we were setting the current node to root
just to guarantee a loop exit, at which point the root would be set to
black. However thi
First, move some code around in order to make the next change more obvious.
commit 16c047add3ceaf0ab882e3e094d1ec904d02312d from linux tree
[a...@linux-foundation.org: coding-style fixes]
Signed-off-by: Peter Zijlstra
Signed-off-by: Wolfram Strepp
Signed-off-by: Andrew Morton
Signed-off-by: Li
The root node of an rbtree must always be black. However,
rb_insert_color() only needs to maintain this invariant when it has been
broken - that is, when it exits the loop due to the current (red) node
being the root. In all other cases (exiting after tree rotations, or
exiting due to an existing
- Use the newly introduced rb_set_parent_color() function to flip the color
of nodes whose parent is already known.
- Optimize rb_parent() when the node is known to be red - there is no need
to mask out the color in that case.
- Flipping gparent's color to red requires us to fetch its rb_parent
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.
commit 4c199a93a2d36b277a9fd209a0f2793f8460a215 from linux tree.
Signed-off-by: Michel Lespinasse
Cc: Andrea Arcangeli
Acked-by: David Woodhouse
Cc: Rik van
It is a well known property of rbtrees that insertion never requires more
than two tree rotations. In our implementation, after one loop iteration
identified one or two necessary tree rotations, we would iterate and look
for more. However at that point the node's parent would always be black,
whi
rbtree users must use the documented APIs to manipulate the tree
structure. Low-level helpers to manipulate node colors and parenthood are
not part of that API, so move them to lib/rbtree.c
commit bf7ad8eeab995710c766df49c9c69a8592ca0216 from linux tree
Signed-off-by: Michel Lespinasse
Cc: Andr
Furthermore, notice that the initial checks:
if (!node->rb_left)
child = node->rb_right;
else if (!node->rb_right)
child = node->rb_left;
else
{
...
}
guarantee that old->rb_righ
There are two cases when a node, having 2 childs, is erased:
'normal case': the successor is not the right-hand-child of the node to be
erased
'special case': the successor is the right-hand child of the node to be
erased
Here some ascii-art, with following symbols (referring to the code):
O: node
Hi All,
The patch imports the changes and updates of the rbtree implementaiton
from Linux tree. But since, the only current implementation is with tmem.c,
which am not much aware off much and therefore, was unable to test the changes
thoroughly. Having said that, I do have plans of adding futher c
flight 109907 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109907/
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
flight 109869 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109869/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
106776
Tests which ar
Hi Stefano,
On 31/05/2017 18:53, Stefano Stabellini wrote:
On Wed, 31 May 2017, Julien Grall wrote:
Hi Stefano,
On 30/05/17 23:35, Stefano Stabellini wrote:
+/*
+ * TODO: lookup currently-in-guest virtual IRQs and migrate them,
+ * as the locking may be fragile otherwise.
+ *
All,
Having a very strange problem. I created a CentOS 7 PV vm but could not get
pygrub to pick-up the grub entries. I did some fault finding and concluded that
`fsimage` was unable to find the grub.cfg.
I could start the vm as an HVM guest with no problem. I renamed the `grub2`
folder to be `gr
Hi Stefano,
On 31/05/2017 18:56, Stefano Stabellini wrote:
On Wed, 31 May 2017, Julien Grall wrote:
Hi Stefano,
On 30/05/17 23:07, Stefano Stabellini wrote:
On Tue, 30 May 2017, Julien Grall wrote:
};
};
@@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
bool use
On Wed, Apr 26, 2017 at 04:54:51PM +0100, Wei Liu wrote:
> We want to have a single entry point to initialise hvm guest. To do
> this, the setting of hap_enabled and creation of the per domain mappings
> is deferred, but that's not a problem.
>
> No functional change.
>
> Signed-off-by: Wei Liu
On 31/05/17 18:57, Juergen Gross wrote:
> On 31/05/17 19:47, Andrew Cooper wrote:
>> xc_{get,set}_hvm_param() are problematic because they truncate their values
>> in
>> a 32bit build.
>>
>> Luckily, this isn't a problem in practice because all values in question
>> should be below 2^32.
>>
>> To
On 31/05/17 19:47, Andrew Cooper wrote:
> xc_{get,set}_hvm_param() are problematic because they truncate their values in
> a 32bit build.
>
> Luckily, this isn't a problem in practice because all values in question
> should be below 2^32.
>
> To expediate the removal of xc_{get,set}_hvm_param() f
On Wed, 31 May 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 30/05/17 23:07, Stefano Stabellini wrote:
> > On Tue, 30 May 2017, Julien Grall wrote:
> > > > };
> > > > };
> > > >
> > > > @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
> > > > bool use_pta)
> > > >
On Wed, 31 May 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 30/05/17 23:35, Stefano Stabellini wrote:
> > > +/*
> > > + * TODO: lookup currently-in-guest virtual IRQs and migrate them,
> > > + * as the locking may be fragile otherwise.
> > > + * This is not easy to do at the mome
xc_{get,set}_hvm_param() are problematic because they truncate their values in
a 32bit build.
Luckily, this isn't a problem in practice because all values in question
should be below 2^32.
To expediate the removal of xc_{get,set}_hvm_param() from libxc, switch
qemu-trad over to using xc_hvm_param
On Wed, 31 May 2017, George Dunlap wrote:
> On 30/05/17 18:29, Stefano Stabellini wrote:
> > On Fri, 26 May 2017, Volodymyr Babchuk wrote:
> > The other issue with stubdoms is context switch times. Volodymyr showed
> > that minios has much higher context switch times compared to EL0 apps.
>
On 26/05/17 20:28, Volodymyr Babchuk wrote:
>> There is no way out: if the stubdom needs events, then we'll have to
>> expose and context switch the vGIC. If it doesn't, then we can skip the
>> vGIC. However, we would have a similar problem with EL0 apps: I am
>> assuming that EL0 apps don't need t
flight 109902 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs.
109900
Tests
Hi Dario,
>> > > On other hand, EL0 app (as I see them) does not need such events.
>> > > Basically, you just call function `handle_mmio()` right in the
>> > > app.
>> > > So, apps can live without interrupts and they still be able to
>> > > handle
>> > > request.
>> >
>> > That's true.
>>
>> Well
On Wed, 2017-05-31 at 10:09 +0100, George Dunlap wrote:
> On 30/05/17 18:29, Stefano Stabellini wrote:
> > On Fri, 26 May 2017, Volodymyr Babchuk wrote:
> > > On other hand, EL0 app (as I see them) does not need such events.
> > > Basically, you just call function `handle_mmio()` right in the
> > >
flight 109866 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109866/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 109828
Tests which did no
On 05/31/2017 11:32 AM, Andrew Cooper wrote:
> On 31/05/17 15:50, Boris Ostrovsky wrote:
>> On 05/31/2017 08:14 AM, Andrew Cooper wrote:
>>> On 31/05/17 08:23, Jan Beulich wrote:
- correct CR3 and CR4 checks
- add vcpu parameter (to include in log messages) and constify vmcb one
- us
On 31/05/17 15:50, Boris Ostrovsky wrote:
> On 05/31/2017 08:14 AM, Andrew Cooper wrote:
>> On 31/05/17 08:23, Jan Beulich wrote:
>>> - correct CR3 and CR4 checks
>>> - add vcpu parameter (to include in log messages) and constify vmcb one
>>> - use bool/true/false
>>> - use accessors
>>> - adjust f
flight 109900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109900/
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
On Tue, May 30, 2017 at 04:05:39AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 17:15, wrote:
> > Changes since v2:
> > - s/vioapic_dom0_map_gsi/vioapic_hwdom_map_gsi/.
> > - Don't set hvm_domid in xen_domctl_bind_pt_irq_t (it's ignored).
>
> The implication of the respective earlier comment
On 05/31/2017 08:14 AM, Andrew Cooper wrote:
> On 31/05/17 08:23, Jan Beulich wrote:
>> - correct CR3 and CR4 checks
>> - add vcpu parameter (to include in log messages) and constify vmcb one
>> - use bool/true/false
>> - use accessors
>> - adjust formatting
>>
>> Signed-off-by: Jan Beulich
>>
>>
On Tue, May 30, 2017 at 04:01:00AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 17:15, wrote:
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -126,6 +126,49 @@ void hvm_pci_intx_deassert(
> > spin_unlock(&d->arch.hvm_domain.irq_lock);
> > }
> >
> > +void hvm_gsi_
>>> On 31.05.17 at 16:08, wrote:
> On 05/31/2017 10:59 AM, Jan Beulich wrote:
> On 30.05.17 at 13:27, wrote:
>>> What about AMD Ryzen iommu Support? Is there any roadmap?
>>
>> Mind being a little more specific? What features are you looking for?
>>
>> It would, btw, also help if you Cc-ed th
On 05/31/2017 07:56 AM, Jan Beulich wrote:
On 31.05.17 at 13:25, wrote:
>> On 31/05/17 08:21, Jan Beulich wrote:
>>> Prevent accidental mistakes by not requiring explicit types to be
>>> specified in the macro invocations.
>>>
>>> Signed-off-by: Jan Beulich
>> I am not a fan of these accesso
timer_deadline is only ever updated via this_cpu() in timer_softirq_action(),
so is not going to change behind the back of the currently running cpu.
Update hpet_broadcast_{enter,exit}() to use this_cpu() rather than per_cpu()
for clarity, and cache the value in a local variable to avoid the repea
On 05/31/2017 10:59 AM, Jan Beulich wrote:
On 30.05.17 at 13:27, wrote:
What about AMD Ryzen iommu Support? Is there any roadmap?
Mind being a little more specific? What features are you looking for?
It would, btw, also help if you Cc-ed the maintainer(s) of the code
you inquire about.
Jan
On 05/31/2017 09:03 AM, Julien Grall wrote:
> Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
> not go far enough to support 64KB in mmap_batch_fn.
>
> The variable 'nr' is the number of 4KB chunk to map. However, when Linux
> is using 64KB page granularity the array o
Armando Vega writes ("Re: [PATCH v2 1/1] xl man page cleanup and fixes"):
> It could be from how I broke the lines to 80 chars, it kept the spaces
> between the words at the end, could that be the problem? I can watch out
> for that in the future.
Yes, that will be it.
However, in general, it is
On 31/05/17 09:52, Julien Grall wrote:
> Hi,
>
> On 05/22/2017 02:32 PM, Jan Beulich wrote:
> On 22.05.17 at 15:12, wrote:
>>> _PAGE_GNTTAB is only used in debug builds of Xen; in release builds,
>>> it has
>>> the value 0. Coverity complains that "l1e_get_flags(l1e) & 0" is
>>> logically
>>>
On Wed, May 31, 2017 at 03:06:15PM +0200, gregory.herr...@oracle.com wrote:
> From: Gregory Herrero
>
> When stop_machine_run() is called with NR_CPUS as last argument,
> fn_result member must be filled only if an error happens since it is
> shared across all cpus.
>
> Assume CPU1 detects an err
On 30/05/17 18:42, Boris Ostrovsky wrote:
This is not worth API change so I guess we are going to have to use
separate calls, as you originally proposed.
Sure. I will stick to making two hypercalls.
Do we need to look at IRQ affinity mask, if we are going to bind
eventchannel to smp_processor
From: Gregory Herrero
When stop_machine_run() is called with NR_CPUS as last argument,
fn_result member must be filled only if an error happens since it is
shared across all cpus.
Assume CPU1 detects an error and set fn_result to -1, then CPU2 doesn't
detect an error and set fn_result to 0. The
Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.
The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma->vm_private_data)
contain one page per 6
Hi,
On 30/05/17 18:41, Feng Kan wrote:
Yap, worked like a charm. Much thanks.
Tested on Centos 7 arm64 system with 4.12rc2 64K page size kernel
(dom0 and domU) & Xen 4.9rc6
Tested-by: Feng Kan
I have sent a slightly different version, so I didn't keep your tested-by.
Cheers,
--
Julien Gral
>>> On 31.05.17 at 14:42, wrote:
> On 15/05/17 15:22, Jan Beulich wrote:
> On 15.05.17 at 15:08, wrote:
>>> On 15/05/17 11:19, Jan Beulich wrote:
>>> On 15.05.17 at 12:08, wrote:
On 12.05.17 at 19:35, wrote:
>> --- a/xen/include/asm-x86/string.h
>> +++ b/xen/include/a
On Tue, May 30, 2017 at 03:16:51AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 17:15, wrote:
> > --- a/xen/arch/x86/irq.c
> > +++ b/xen/arch/x86/irq.c
> > @@ -2537,3 +2537,162 @@ bool_t hvm_domain_use_pirq(const struct domain *d,
> > const struct pirq *pirq)
> > return is_hvm_domain(d) &&
On Wed, May 31, 2017 at 12:41:32PM +0200, gregory.herr...@oracle.com wrote:
> From: Gregory Herrero
>
> @@ -150,8 +155,11 @@ static void stopmachine_action(unsigned long cpu)
> case STOPMACHINE_INVOKE:
> if ( (stopmachine_data.fn_cpu == smp_processor_id()) ||
>
On 31/05/17 08:49, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> Suggested-by: Boris Ostrovsky
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 15/05/17 15:22, Jan Beulich wrote:
On 15.05.17 at 15:08, wrote:
>> On 15/05/17 11:19, Jan Beulich wrote:
>>> >>> On 15.05.17 at 12:08, wrote:
>>> On 12.05.17 at 19:35, wrote:
> --- a/xen/include/asm-x86/string.h
> +++ b/xen/include/asm-x86/string.h
> @@ -2,13 +2,23 @@
>>
According to SDM Chapter ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC)
-> Extended XAPIC (x2APIC) -> x2APIC State Transitions, The existing code to
handle guest's writing MSR_IA32_APICBASE has two flaws:
1. Transition from x2APIC Mode to Disabled Mode is allowed but wrongly
disabled currently.
flight 109894 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109894/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3)broken REGR. vs.
On 31/05/17 08:51, Jan Beulich wrote:
> While f32400e90c ("x86: fix build with gcc 7")'s change to
> compat_array_access_ok() is necessary, I had blindly and needlessly
> also added it to array_access_ok(). There's no conditional expression
> involved there, so undo it.
>
> Signed-off-by: Jan Beuli
On 31/05/17 08:38, Jan Beulich wrote:
> It doesn't alter the image in any way.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, May 31, 2017 at 02:10:27PM +0200, Armando Vega wrote:
> I'm not sure I know what you mean, do you mean spaces trailing some of
> the lines?
>
Yes.
> It could be from how I broke the lines to 80 chars, it kept the spaces
> between the words at the end, could that be the problem? I can wat
On 31/05/17 08:23, Jan Beulich wrote:
> - correct CR3 and CR4 checks
> - add vcpu parameter (to include in log messages) and constify vmcb one
> - use bool/true/false
> - use accessors
> - adjust formatting
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/
flight 109862 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109862/
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.
109711
Regressions
On 05/31/2017 01:01 PM, Ian Jackson wrote:
> Armando Vega writes ("[PATCH v2 0/1] xl man page cleanup and fixes proposal"):
>> thanks for the ack Ian, I'm glad you found it helpful!
>> I amended the commit message to include my sign-off and Ian's ack.
>> I'll send a PR on github once I get your ok
On Wed, May 31, 2017 at 01:24:52AM -0600, Jan Beulich wrote:
> Have the caller indicate its buffer size, provide a means to query the
> needed size, don't ignore the upper halves of type code and instance,
> and don't copy partial data.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
I'm not sure I know what you mean, do you mean spaces trailing some of
the lines?
It could be from how I broke the lines to 80 chars, it kept the spaces
between the words at the end, could that be the problem? I can watch out
for that in the future.
On 05/31/2017 11:46 AM, Wei Liu wrote:
> On We
1 - 100 of 198 matches
Mail list logo
