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
>>> 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
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
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 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
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
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/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
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
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
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
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:
>
>
> 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
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
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.
>
On 12/12/2018 17:59, Andrii Anisov wrote:
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
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
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
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
>>> 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
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
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
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
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
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
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
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.
...
>
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
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
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
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:
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
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 +
>
>>> 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
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
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
>>> 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,
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
>
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
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
flight 131233 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131233/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 130985
Regressions which
flight 131231 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
On 12/12/2018 12:39 PM, Borislav Petkov wrote:
On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote:
Is your question about what options you need to provide to Qemu? Or is your
question about the SW implementation choices?
Assuming the former...
Yeah, that's what I wanted to know.
flight 131274 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131274/
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
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
No changes in v2:
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
From: Andrii Anisov
Under desc->lock taken:
An IRQ with _IRQ_GUEST flag set always has an action.
An IRQ with _IRQ_DISABLED flag cleared always has an action.
Those flags checks cover all accesses to desc->action in do_IRQ,
so we can skip desc->action check in non-debug build.
Keep in place for
On Wed, 12 Dec 2018, Julien Grall wrote:
> 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/
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid xen-boot/dst_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid xen-boot/src_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
> On Dec 12, 2018, at 3:45 PM, Ian Jackson wrote:
>
> 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
On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote:
> Is your question about what options you need to provide to Qemu? Or is your
> question about the SW implementation choices?
>
> Assuming the former...
Yeah, that's what I wanted to know. But looking at it, I'm booting
bzImage here
flight 131224 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898
flight 131238 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131238/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-libvirt 13
flight 131284 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131284/
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
btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
though I didn't see a reason why code in-between may impact those
bits, it doesn't hurt to capture the context right before interrupt is
raised. :-)
> -Original Message-
> From: Tian, Kevin
> Sent: Thursday, December
On Thu, 29 Nov 2018, Julien Grall wrote:
> Xen mapping is first create using a 2MB page and then shatterred in 4KB
> page for fine-graine permission. However, it is not safe to break-down
> superpage page without going to an intermediate step invalidating
> the entry.
>
> As we are changing Xen
flight 131240 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail REGR. vs.
131172
Tests which
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, December 12, 2018 8:18 PM
>
> 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
On 12/12/18 2:26 AM, Jan Beulich wrote:
On 11.12.18 at 19:16, wrote:
>> BTW: Apart from the fact its ugly and take a lng time to complete, do you
>> have any practical isssues you want to highlight? maybe that can
>> help upstream as well.
> The situation for a kernel and a hypervisor
flight 131245 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131245/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Wed, 12 Dec 2018, Julien Grall wrote:
> 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
>
On Thu, 29 Nov 2018, Julien Grall wrote:
> At the moment, Xen is relocated towards the end of the memory. While
> this has the advantage to free space in low memory, the code is not
> compliant with the break-before-make because it requires to switch
> between two sets of page-table. This is not
On Wed, 12 Dec 2018, Julien Grall wrote:
> 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
On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
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
flight 131256 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 131219
On Wed, 12 Dec 2018, Julien Grall wrote:
> 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
> > > >
On Tue, 11 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 03/12/2018 21:03, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > Introduce data structs to implement basic access controls.
> > Introduce the following three functions:
> >
> >
On Wed, 5 Dec 2018, Jan Beulich wrote:
> >>> On 04.12.18 at 20:38, wrote:
> > On Tue, 4 Dec 2018, Jan Beulich wrote:
> >> >>> On 03.12.18 at 22:03, wrote:
> >> > To be used in constant initializations of mfn_t variables, such as:
> >> >
> >> > static mfn_t node = mfn_init(MM_ADDR);
> >> >
> >>
flight 131255 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, December 6, 2018 11:34 PM
>
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames
> the
> existing functions to iommu_legacy_map/unmap() and
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, December 1, 2018 1:07 AM
>
> 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
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, December 6, 2018 11:34 PM
>
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and adds new iommu_map/unmap()
> wrapper
> functions. To maintain sematics of the
>>> On 13.12.18 at 04:46, wrote:
> On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
> 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
flight 131265 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131265/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 25cda747b021a1be758d3d1b128a670a23841f7f
baseline version:
freebsd
>>> On 12.12.18 at 18:05, wrote:
> On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
>> The MMIO side of things of course still remains unclear.
>
> Right, for the MMIO and the handling of grant and foreign mappings it's
> not clear how we want to proceed.
>
> Maybe account for all
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, December 8, 2018 4:07 AM
> nested vmx mode
>
> By default on capable hardware,
> SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
> activated unilaterally. The VMCS Link pointer is initialised to ~0, but the
> VMREAD/VMWRITE
>>> 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
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
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 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
> > ---
> >
>>> 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
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
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,
>>> 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,
> +
>>> 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
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
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
> 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 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
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
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()/
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
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
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
>>> 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
1 - 100 of 136 matches
Mail list logo
