>>> On 11.12.18 at 19:05, wrote:
> On Fri, Oct 26, 2018 at 05:20:47AM -0600, Jan Beulich wrote:
>> >>> On 26.10.18 at 12:51, wrote:
>> > The basic solution involves having a xenheap virtual address mapping
>> > area not tied to the physical layout of the memory. domheap and xenheap
>> > memory w
>>> On 12.12.18 at 08:06, wrote:
> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
I find some pass-thru devices don't work any more across guest reboot.
Assigning
On Fri, Nov 02, Kevin Wolf wrote:
> A while ago, a downstream patch review found out that there are some QMP
> commands that would immediately crash if a xen_disk device were present
> because of the lacking qdevification. This is not the code quality
> standard I envision for QEMU. It's time for
On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
> >>> On 11.12.18 at 16:19, wrote:
> > On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
> >> >>> On 05.12.18 at 15:54, wrote:
> >> > To note it's calculating the approximate amount of memory required by
> >> > shadow paging.
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 12 December 2018 09:00
> To: Kevin Wolf
> Cc: Tim Smith ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; arm...@redhat.com; qemu-
> de...@nongnu.org; Max Reitz ; Paul Durrant
> ; Anthony Perard ;
> xen-devel@lists.xenp
Hello Julien,
On 11.12.18 14:27, Julien Grall wrote:
I would like to have performance per patch so we can make the decisions whether
the implementation cost is worth it for upstream.
I'll check baremetal numbers first. Then will get numbers per patch.
--
Sincerely,
Andrii Anisov.
___
On Tue, Dec 11, 2018 at 09:21:29AM -0700, Jan Beulich wrote:
> >>> On 11.12.18 at 16:36, wrote:
> > On Tue, Dec 11, 2018 at 08:19:34AM -0700, Jan Beulich wrote:
> >> >>> On 05.12.18 at 15:55, wrote:
> >> > +unsigned long __init dom0_hap_pages(const struct domain *d,
> >> > +
Hello Dario,
On 11.12.18 18:56, Dario Faggioli wrote:
Also, what about Xen numbers, sched=null.
Didn't check, will put on the list.
I don't expect much improvement, considering pinning is in-place
already.
Actually, I faced a strange issue with explicit pinning of Dom0. Didn't sort
out the
On 11.12.18 21:29, Stefano Stabellini wrote:
Yes, I think the uart driver could be sufficient, but it has only the
Xilinx uart, the pl011 and the Xen emergency console. If I recall
correctly, Renesas needs a different driver. Any platform specific
initialization would also need to be added to it
>>> On 01.12.18 at 02:32, wrote:
> +static inline uint16_t
> +argo_hash_fn(const struct argo_ring_id *id)
We generally prefer to avoid "inline" outside of header files. Also
is there any strict need for the function to return a fixed width
type? Plus what's the point of the _fn suffix?
> +{
> +
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most needed fu
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
pointers and multi-touch devices all allowing Xen to be used in
automotive appliances, In-Vehicle Infotainment (IVI) systems
and
>>> On 01.12.18 at 02:32, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -510,6 +510,59 @@ argo_ring_find_info(const struct domain *d, const struct
> argo_ring_id *id)
> }
>
> static long
> +argo_unregister_ring(struct domain *d,
> + XEN_GUEST_HANDLE_PARAM
>>> On 12.12.18 at 10:14, wrote:
> On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
>> >>> On 11.12.18 at 16:19, wrote:
>> > On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
>> >> >>> On 05.12.18 at 15:54, wrote:
>> >> > To note it's calculating the approximate amount of
flight 131264 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131264/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a9c904c5a827144eb722cfb46634c60b739e19eb
baseline version:
xen 58eb
>>> On 12.12.18 at 10:37, wrote:
> OK, I will iterate over all the devices in order to size the BARs, and
> then add the sum of BARs MMIO regions to the amount of guest memory,
> so that each 1MB of BAR MMIO will require 1 page for the p2m.
Don't you construct a rangeset for all of the BARs alrea
On Wed, Dec 12, 2018 at 02:53:26AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 10:14, wrote:
> > On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
> >> >>> On 11.12.18 at 16:19, wrote:
> >> > On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
> >> >> >>> On 05.12.18 at 15:
On Wed, Dec 12, 2018 at 02:59:42AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 10:37, wrote:
> > OK, I will iterate over all the devices in order to size the BARs, and
> > then add the sum of BARs MMIO regions to the amount of guest memory,
> > so that each 1MB of BAR MMIO will require 1 page f
Hi Stefano,
On 11/12/2018 19:22, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Hi,
On 03/12/2018 21:03, Stefano Stabellini wrote:
What is the plan there?
The plan is to extract the node_id from a power-domain node on device
tree. Each device would have a phandler to link
>>> On 12.12.18 at 11:04, wrote:
> On Wed, Dec 12, 2018 at 02:53:26AM -0700, Jan Beulich wrote:
>> >>> On 12.12.18 at 10:14, wrote:
>> > On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
>> >> >>> On 11.12.18 at 16:19, wrote:
>> >> > On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beuli
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Monday, October 15, 2018 6:30 PM
> (XEN) [22642] POWERTYPE 4
> (XEN) [22643] IDLE PPR 0x0020
> (XEN)IRR
> 00
> 00
> (XEN)
On 12.12.18 11:46, Andrii Anisov wrote:
Digging into that now.
I got it. My u-boot starts TBM in hyp mode. But them both miss setting
HCR_EL2.IMO, so no interrupt exception was taken in hyp.
OK, for my baremetal TBM in hyp, numbers are:
max=840 warm_max=120 min=120 avg=127
I guess, warm_max
On 11/12/2018 22:23, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote:
> Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
> a écrit :
> >
> > Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> > a écrit :
> > >
> > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > > Having the probe h
On Mon, Dec 10, 2018 at 12:12:05PM +0200, Oleksandr Andrushchenko wrote:
> On 12/10/18 12:03 PM, Daniel Vetter wrote:
> > Doesn't do anything for atomic.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Oleksandr Andrushchenko
> > Cc: xen-de...@lists.xen.org
> > ---
> > drivers/gpu/drm/xen/xen_drm
>>> On 12.12.18 at 11:16, wrote:
> There are also further issues that I wanted to discuss in a separate
> thread, what about foreign mappings? Dom0 will likely map a non
> trivial amount of grants and foreign mappings, which will also require
> p2m/IOMMU page table entries.
Hmm, good point. Then
Hello Julien,
On 11.12.18 16:33, Julien Grall wrote:
With #ifndef NDEBUG and the appropriate comment:
Will do.
Reviewed-by: Julien Grall
Thank you.
Feel free to resent it alone so it can be merged to Xen 4.12.
What about getting it together with "[RFC 11/16] irq: skip action avalability
From: Tim Smith
The xen-block dataplane currently allocates memory to hold the data for
each request as that request is used, and frees it afterwards. Because
it requires page-aligned blocks, this interacts poorly with non-page-
aligned allocations and balloons the heap.
Instead, allocate the ma
From: Tim Smith
If the I/O ring is full, the guest cannot send any more requests
until some responses are sent. Only sending all available responses
just before checking for new work does not leave much time for the
guest to supply new work, so this will cause stalls if the ring gets
full. Also,
From: Tim Smith
When I/O consists of many small requests, performance is improved by
batching them together in a single io_submit() call. When there are
relatively few requests, the extra overhead is not worth it. This
introduces a check to start batching I/O requests via blk_io_plug()/
blk_io_un
On Wed, Dec 12, 2018 at 03:57:41AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 11:16, wrote:
> > There are also further issues that I wanted to discuss in a separate
> > thread, what about foreign mappings? Dom0 will likely map a non
> > trivial amount of grants and foreign mappings, which will
This series is a re-base of Tim's v2 series [1] on top of my series [2].
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00243.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02271.html
Tim Smith (3):
xen-block: improve batching behaviour
xen-block: improve resp
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 12 December 2018 11:14
> To: qemu-...@nongnu.org; qemu-bl...@nongnu.org; xen-
Fat-fingered the email address, I'll send again.
Paul
> de...@lists.xenproject.org
> Cc: Paul Durrant ; Anthony Perard
> ; Ke
From: Tim Smith
When I/O consists of many small requests, performance is improved by
batching them together in a single io_submit() call. When there are
relatively few requests, the extra overhead is not worth it. This
introduces a check to start batching I/O requests via blk_io_plug()/
blk_io_un
From: Tim Smith
If the I/O ring is full, the guest cannot send any more requests
until some responses are sent. Only sending all available responses
just before checking for new work does not leave much time for the
guest to supply new work, so this will cause stalls if the ring gets
full. Also,
From: Tim Smith
The xen-block dataplane currently allocates memory to hold the data for
each request as that request is used, and frees it afterwards. Because
it requires page-aligned blocks, this interacts poorly with non-page-
aligned allocations and balloons the heap.
Instead, allocate the ma
This series is a re-base of Tim's v2 series [1] on top of my series [2].
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00243.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02271.html
Tim Smith (3):
xen-block: improve batching behaviour
xen-block: improve resp
On Wed, Dec 12, 2018 at 12:14:53PM +0100, Roger Pau Monné wrote:
> On Wed, Dec 12, 2018 at 03:57:41AM -0700, Jan Beulich wrote:
> > >>> On 12.12.18 at 11:16, wrote:
> > > There are also further issues that I wanted to discuss in a separate
> > > thread, what about foreign mappings? Dom0 will likel
On Wed, Dec 12, 2018 at 10:36:44AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Monday, October 15, 2018 6:30 PM
> > (XEN) [22642] POWERTYPE 4
> > (XEN) [22643] IDLE PPR 0x0020
> > (XEN)IRR
> > 00
On 11.12.18 16:48, Julien Grall wrote:
And you can't see any potential race in that code happening in the future?
It is protected with `desc->lock` so far. If one decided to get it from under
the lock, the race is possible with `release_irq()`.
Also getting an unknown
interrupt is very unli
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, December 12, 2018 7:25 PM
>
> On Wed, Dec 12, 2018 at 10:36:44AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Monday, October 15, 2018 6:30 PM
> > > (XEN) [22642] POWER
>>> On 01.12.18 at 02:32, wrote:
> +static void
> +argo_signal_domain(struct domain *d)
> +{
> +argo_dprintk("signalling domid:%d\n", d->domain_id);
> +
> +if ( !d->argo ) /* This can happen if the domain is being destroyed */
> +return;
If such a precaution is necessary, how is i
On 12/12/2018 11:01, Andrii Anisov wrote:
Hello Julien,
On 11.12.18 16:33, Julien Grall wrote:
With #ifndef NDEBUG and the appropriate comment:
Will do.
Reviewed-by: Julien Grall
Thank you.
Feel free to resent it alone so it can be merged to Xen 4.12.
What about getting it together wi
On 12/12/2018 11:30, Andrii Anisov wrote:
On 11.12.18 16:48, Julien Grall wrote:
And you can't see any potential race in that code happening in the future?
It is protected with `desc->lock` so far. If one decided to get it from under
the lock, the race is possible with `release_irq()`.
A
Hi
On Mon, Dec 10, 2018 at 8:55 PM Igor Mammedov wrote:
>
> On Mon, 10 Dec 2018 17:45:22 +0100
> Igor Mammedov wrote:
>
> > On Tue, 4 Dec 2018 18:20:11 +0400
> > Marc-André Lureau wrote:
> >
> > > Instead of registering compat properties as globals, let's keep them
> > > in their own array, to
Am 12.12.2018 um 09:59 hat Olaf Hering geschrieben:
> On Fri, Nov 02, Kevin Wolf wrote:
>
> > A while ago, a downstream patch review found out that there are some QMP
> > commands that would immediately crash if a xen_disk device were present
> > because of the lacking qdevification. This is not t
Olaf Hering writes:
> On Fri, Nov 02, Kevin Wolf wrote:
>
>> A while ago, a downstream patch review found out that there are some QMP
>> commands that would immediately crash if a xen_disk device were present
>> because of the lacking qdevification. This is not the code quality
>> standard I envi
Hi,
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
Those fucntions are called under IRQs disabled already, so avoid
s/fucntions/
additional flags saving and restore.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic-vgic.c | 10 --
1 file changed, 4 insertions(+
Hi,
On 28/11/2018 22:06, Julien Grall wrote:
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
This reduces the number of context switches in case we have an
interrupt storm. We will read out all of those interrupt in the
loop anyway.
This needs a better explanation. You might w
On Wed, Dec 12, 2018 at 11:48:52AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Wednesday, December 12, 2018 7:25 PM
> >
> > On Wed, Dec 12, 2018 at 10:36:44AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > >
On 12.12.18 14:07, Julien Grall wrote:
This chunk relies on patch #1, am I correct?
For sure, it is.
If so, this should be written in the commit message that this was introduced
recently.
This helps to figure out whether the patch can be merged before the rest.
Do you mean I can prepare
Julien,
Sorry for bothering you too much.
What about this patch?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Andrii,
On 12/12/2018 12:35, Andrii Anisov wrote:
On 12.12.18 14:07, Julien Grall wrote:
This chunk relies on patch #1, am I correct?
For sure, it is.
If so, this should be written in the commit message that this was introduced
recently.
This helps to figure out whether the patch can
Hi,
On 12/12/2018 12:37, Andrii Anisov wrote:
Julien,
Sorry for bothering you too much.
What about this patch?
I haven't answered because I am waiting the numbers.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 12.12.18 14:44, Julien Grall wrote:
At the moment, I am happy with the second chunk of this patch to go. I am still
unconvinced #1 is the right thing to go.
I got it. So keep the patch still for now.
I plan to send separately patches you have reviewed first. Then evaluate the
rest with
On 12.12.18 14:46, Julien Grall wrote:
I haven't answered because I am waiting the numbers.
I got it.
But TBM will not show effect of this patch. Even the patch breaks TBM's
functionality because TBM relies on a phys timer interrupt to be assigned to
the domain (go through the spi path).
--
Hi,
On 12/12/2018 12:52, Andrii Anisov wrote:
On 12.12.18 14:46, Julien Grall wrote:
I haven't answered because I am waiting the numbers.
I got it.
But TBM will not show effect of this patch.
If TBM does not show effect, then you need a different benchmark. Probably by
looking at how the
Julien,
On 12.12.18 13:59, Julien Grall wrote:
An ASSERT(...) is already embed in irq_get_guest_info(desc).
Yep.
I thought about the ASSERT(...) over the current printk yesterday. But I
discarded it because it does not give you more information if something went
really wrong as the stack t
Jan Beulich writes ("Re: [Xen-devel] [xen-4.10-testing test] 131151:
regressions - FAIL"):
> So this can, by now, be called a reliably recurring failure.
I concur with the assertions made on irc that 129676 got an (un)lucky
pass and that it should be force pushed. So I have done that, with
b6e
Hi,
On 12/12/2018 13:51, Andrii Anisov wrote:
Julien,
On 12.12.18 13:59, Julien Grall wrote:
An ASSERT(...) is already embed in irq_get_guest_info(desc).
Yep.
I thought about the ASSERT(...) over the current printk yesterday. But I
discarded it because it does not give you more information
Callbacks should be in the order that there are going to be executed.
This patch fix the initiate_domain_create callbacks, and also reorder
the callbacks prototytes. That way, it's easier to follow the flow.
This patch:
- move libxl__colo_restore_setup_done after domcreate_bootloader_done.
- move
When the caller of paging_log_dirty_op is a paging mode guest Xen
would choke when trying to copy the dirty bitmap to the guest provided
buffer because the paging lock of the target is already locked, and
trying to lock the paging lock of the caller will cause the mm lock
order checks to trigger:
On 12.12.18 16:49, Julien Grall wrote:
ASSERT only tells you that desc->action was NULL. It does not tell you which IRQ
has the desc->action == NULL.
Ah, yes.
It is a bit a shame we don't have way to provide another message with ASSERT to
help you debugging.
We might have implemented an a
On 12/12/2018 14:58, Andrii Anisov wrote:
On 12.12.18 16:49, Julien Grall wrote:
ASSERT only tells you that desc->action was NULL. It does not tell you which
IRQ has the desc->action == NULL.
Ah, yes.
It is a bit a shame we don't have way to provide another message with ASSERT
to help you
On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
On 12.12.18 at 08:06, wrote:
>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
> I find some pass-thr
Improve decision when vTSC emulation will be activated for a domU with
tsc_mode=default. The current approach is to compare the cpu_khz value
from two physical hosts. Since this value is not accurate, it can not be
used verbatim to decide if vTSC emulation needs to be enabled. Without
this change e
>>> On 12.12.18 at 16:18, wrote:
> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
> On 12.12.18 at 08:06, wrote:
>>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
On 12/5/18 4:32 AM, Roger Pau Monné wrote:
> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Ch
George Dunlap writes ("[PATCH v2 03/10] libxl: Clean up
userlookup_helper_getpw* helper"):
> Bring conventions more in line with libxl__xs_read_checked():
> - If found, return 0 and set pointer to non-NULL
> - If not found, return 0 and set pointer to NULL
> - On error, return libxl-style error nu
On 07/12/2018 21:29, Stefano Stabellini wrote:
CC'ing Dario
Dario, please give a look at the preemption question below.
On Fri, 7 Dec 2018, Julien Grall wrote:
On 06/12/2018 23:32, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
So you may not execute them before returni
George Dunlap writes ("[PATCH v2 05/10] libxl: Do root checks once in
libxl__domain_get_device_model_uid"):
> At the moment, we check for equivalence to literal "root" before
> deciding whether to add the `runas` command-line option to QEMU. This
> is unsatisfactory for several reasons.
...
> v2:
George Dunlap writes ("[PATCH v2 07/10] 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 structures and callback function signatures. Add the
> state structu
On Wed, Dec 12, 2018 at 03:32:53AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 11:04, wrote:
> > On Wed, Dec 12, 2018 at 02:53:26AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 10:14, wrote:
> >> > On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
> >> >> >>> On 11.12.18 at 16:
On 12.12.18 17:08, Julien Grall wrote:
Is it just because it adds a couple more instruction in the guest case?
And add unlikely for XEN IRQ case. That was the idea.
The check is mainly there to catch error in debug build.
I supposed a race with `release_irq()`, but found out that we are safe
On Fri, Nov 30, 2018 at 05:32:46PM -0800, Christopher Clark wrote:
> 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
>>> On 12.12.18 at 15:54, wrote:
> Fix this by releasing the target paging lock before attempting to
> perform the copy of the dirty bitmap, and then forcing a restart of
> the whole process in case there have been changes to the dirty bitmap
> tables.
I'm afraid it's not that simple: The writer
>>> On 12.12.18 at 16:56, wrote:
> On Wed, Dec 12, 2018 at 03:32:53AM -0700, Jan Beulich wrote:
>> >>> On 12.12.18 at 11:04, wrote:
>> > You mentioned there's some code (for PV?) to calculate the size of the
>> > page tables but I'm having trouble finding it (mainly because I'm not
>> > that fami
George Dunlap writes ("[PATCH v2 08/10] libxl: Kill QEMU by uid when possible"):
> The privcmd fd that a dm_restrict'ed QEMU has gives it permission to
> one specific domain ID. This domain ID will probably eventually be
> used again. It is therefore necessary to make absolutely sure that a
> rog
Hi Stefano,
On 11/12/2018 18:46, Stefano Stabellini wrote:
cplen is unsigned, thus, it can never be < 0. Use a signed integer local
variable instead.
The current code checks > 0. Looking at the code I don't think it can ever be
negative. So can you details what is the problem you are trying t
George Dunlap writes ("[PATCH v2 09/10] libxl: Kill QEMU with "reaper" ruid"):
> Using kill(-1) to killing an untrusted dm process with the real uid
> equal to the dm_uid isn't guaranteed to succeed: the process in
> question may be able to kill the reaper process after the setresuid()
> and before
George Dunlap writes ("[PATCH v2 10/10] dm_depriv: Mark `UID cleanup` as
completed"):
> Signed-off-by: George Dunlap
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-dev
>>> On 12.12.18 at 16:20, wrote:
> Improve decision when vTSC emulation will be activated for a domU with
> tsc_mode=default. The current approach is to compare the cpu_khz value
> from two physical hosts. Since this value is not accurate, it can not be
> used verbatim to decide if vTSC emulation
On Fri, Dec 07, 2018 at 07:05:38PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] libxl: Documentation about the domain
> configuration on disk"):
> > On Thu, Dec 06, 2018 at 02:57:33PM +, Anthony PERARD wrote:
> > > Anyway, that comment block isn't very helpful because it basically
On Fri, Nov 30, 2018 at 05:32:52PM -0800, Christopher Clark wrote:
> 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
From: Andrii Anisov
This action is excessive because for an invalid LR there is no need
to write another invalid value to a register. So we can skip it here,
saving a peripheral register write.
Keep clearing the LR for the DEBUG build. This would make dumped
invalid LRs be zero. That is more obvi
From: Andrii Anisov
An IRQ with _IRQ_GUEST flag set always has an action.
An IRQ with _IRQ_DISABLED flag cleared always have an action.
Those flags checks cover all accesses to desc->action in do_IRQ,
so we can skip desc->action check.
Still keep it in place for debug build.
Signed-off-by: Andri
From: Andrii Anisov
Here are few patches from RFC series [1] currently approved to
be upstreamed with appropriate changes.
Andrii Anisov (2):
gic-vgic: Drop an excessive clear_lrs
Is a patch #5 [2], with a change:
- Keep LR clear for debug build
arm/irq: skip action availab
On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 16:56, wrote:
> > On Wed, Dec 12, 2018 at 03:32:53AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 11:04, wrote:
> >> > You mentioned there's some code (for PV?) to calculate the size of the
> >> > page tables b
On Wed, 2018-12-12 at 11:39 +0200, Andrii Anisov wrote:
> Hello Dario,
>
Hi,
> On 11.12.18 18:56, Dario Faggioli wrote:
> > Also, what about Xen numbers, sched=null.
> Didn't check, will put on the list.
>
:-)
> > I don't expect much improvement, considering pinning is in-place
> > already.
> A
On Wed, 12 Dec 2018, Julien Grall wrote:
> On 07/12/2018 21:29, Stefano Stabellini wrote:
> > CC'ing Dario
> >
> > Dario, please give a look at the preemption question below.
> >
> >
> > On Fri, 7 Dec 2018, Julien Grall wrote:
> > > On 06/12/2018 23:32, Stefano Stabellini wrote:
> > > > On Tue,
Hello Dario,
On 12.12.18 19:10, Dario Faggioli wrote:
Ah, yes... I've seen the thread. I haven't commented, as it is really,
really weird, and I don't know what to think/say.
I think only bisection could shed some light on this. And it would be
wonderful if you could do that, but I understand t
On 12/12/2018 7:28 AM, Stefano Garzarella wrote:
On Tue, Dec 11, 2018 at 7:35 PM Maran Wilson wrote:
On 12/11/2018 9:11 AM, Stefano Garzarella wrote:
Hi Liam,
in order to support PVH also with SeaBIOS, I'm going to work on a new
option rom (like linuxboot/multiboot) that can be used in this ca
> On Dec 12, 2018, at 3:26 PM, Ian Jackson wrote:
>
> George Dunlap writes ("[PATCH v2 03/10] libxl: Clean up
> userlookup_helper_getpw* helper"):
>> Bring conventions more in line with libxl__xs_read_checked():
>> - If found, return 0 and set pointer to non-NULL
>> - If not found, return 0 an
On Wed, 12 Dec 2018, Andrii Anisov wrote:
> On 12.12.18 11:46, Andrii Anisov wrote:
> > Digging into that now.
> I got it. My u-boot starts TBM in hyp mode. But them both miss setting
> HCR_EL2.IMO, so no interrupt exception was taken in hyp.
> OK, for my baremetal TBM in hyp, numbers are:
>
> max
Hello Stefano,
On 12.12.18 19:39, Stefano Stabellini wrote:
Thanks for the good work, Andrii!
The WARM_MAX improvements for vwfi=native with your optimizations are
impressive.
I really hope you are not speaking about these numbers:
max=840 warm_max=120 min=120 avg=127
Those are TBM barem
Title: s/avalability/availability/
On 12/12/2018 16:55, Andrii Anisov wrote:
From: Andrii Anisov
An IRQ with _IRQ_GUEST flag set always has an action.
An IRQ with _IRQ_DISABLED flag cleared always have an action.
s/have/has/
Those conditions are not sufficient to ensure desc->action is not
On Wed, 2018-12-12 at 09:25 -0800, Stefano Stabellini wrote:
> On Wed, 12 Dec 2018, Julien Grall wrote:
> > > For Dario: basically we have a long running operation to perform,
> we
> > > thought that the best place for it would be on the path returning
> to
> > > guest (leave_hypervisor_tail). The
On 12.12.18 19:49, Julien Grall wrote:
Please don't add a reviewed-by tag until it was explicitly written by the
reviewer.
My bad, I mixed it with #5.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:/
On 12.12.18 19:49, Julien Grall wrote:
Those conditions are not sufficient to ensure desc->action is not NULL. You
also need to take the spinlock.
Agree. Should I describe it as following?
Under desc->lock taken:
An IRQ with _IRQ_GUEST flag set always has an action.
An IRQ with _IRQ_DISABLED
On Wed, 2018-12-12 at 19:32 +0200, Andrii Anisov wrote:
> On 12.12.18 19:10, Dario Faggioli wrote:
> > I think only bisection could shed some light on this. And it would
> > be
> > wonderful if you could do that, but I understand that it takes
> > time. :-
> > /
> Well, bisect might help. But I'm r
On Wed, 12 Dec 2018, Andrii Anisov wrote:
> Hello Stefano,
>
> On 12.12.18 19:39, Stefano Stabellini wrote:
> > Thanks for the good work, Andrii!
> >
> > The WARM_MAX improvements for vwfi=native with your optimizations are
> > impressive.
>
> I really hope you are not speaking about these numbe
1 - 100 of 142 matches
Mail list logo
