flight 112348 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 2 hosts-allocate broken REGR. vs. 110515
build-arm64-pvops
On 27/07/17 20:20, PGNet Dev wrote:
> I've upgraded a Xen server's
>
> xen-4.9.0_08-517.2.x86_64
> xen-libs-4.9.0_08-517.2.x86_64
>
> kernel from 4.12x to 4.13x
>
> uname -rm
> 4.13.0-rc2-2.gb545b87-default x86_64
>
> After upgrading, I see in my Dom0-attached se
Is it possible to use VFB for paravirtualised Guest? How to display
Domain-U in physical monitor? I have added vfb in my Guest configuration
and it returns the following error :
Parsing config from
/etc/xen/arch_domU_1.cfg
libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model
/usr/lib/
flight 112344 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 2 hosts-allocate broken REGR. vs. 111765
build-arm64-xsm
On Thu 27.Jul'17 at 12:06:10 -0400, Boris Ostrovsky wrote:
(Adjusting addressees: David is no longer maintaining Xen code, Juergen is)
Thanks Boris.
On 07/27/2017 09:04 AM, shuo.a@intel.com wrote:
Hi,
Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost
interrupt during dr
flight 112340 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112340/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 4 host-install(4)broken REGR. vs. 112286
build-arm64-xsm
This run is configured for baseline tests only.
flight 71900 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71900/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c2c68b9d3e83af26042f03f9864fd38ce922a89
baseline v
> On Jul 27, 2017, at 6:11 PM, Andreas Kinzler wrote:
>
> On Thu, 27 Jul 2017 18:49:47 +0200, George Dunlap
> wrote:
>>> Sorry, I think that this patch is just far to complicated. If you really
>>> want to keep the "iptables is working check" (lines 1-7 of function
>>> handle_iptable) then y
flight 112346 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112346/
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 13 mig
On Thu, 27 Jul 2017, Olaf Hering wrote:
> On Tue, Jun 27, Stefano Stabellini wrote:
>
> > From: Paul Durrant
> > The blkif protocol has had provision for negotiation of multi-page shared
> > rings for some time now and many guest OS have support in their frontend
> > drivers.
>
> > +++ b/hw/bloc
> +int pvcalls_front_release(struct socket *sock)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + int req_id, notify;
> + struct xen_pvcalls_request *req;
> +
> + if (!pvcalls_front_dev)
> + return -EIO;
> + bedata = dev_get_drvdata(&pv
Quick info/update:
> XSA-222: line 51 in the log shows a real difference: this is a known bug
> in the tool where the diff file chunks are in a different order
This is now fixed in the last version of the scripts and the script
correctly handles this case
Lars
On 18/07/2017, 18:43, "Lars Kurth"
This run is configured for baseline tests only.
flight 71883 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71883/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) bloc
I've upgraded a Xen server's
xen-4.9.0_08-517.2.x86_64
xen-libs-4.9.0_08-517.2.x86_64
kernel from 4.12x to 4.13x
uname -rm
4.13.0-rc2-2.gb545b87-default x86_64
After upgrading, I see in my Dom0-attached serial console, a steady stream of,
...
This run is configured for baseline tests only.
flight 71884 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71884/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1d8701a20e02f8c2c3ca66bb643d45d7d6779fd1
baseline v
flight 112342 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112342/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c2c68b9d3e83af26042f03f9864fd38ce922a89
baseline version:
ovmf 9cb74c3693f157e7bc00e
flight 112338 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-py
Provide a SYSCTL for the toolstack to obtain complete system cpuid policy
information. The CPUID information is serialised as an array of 6x 32bit
integers, and a mechanism is provided to query the maximum number of entries
Xen might write.
For the XSM side of things, this subop is closely relate
flight 112345 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112345/
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 13 mig
On Thu, 27 Jul 2017 18:49:47 +0200, George Dunlap
wrote:
Sorry, I think that this patch is just far to complicated. If you
really want to keep the "iptables is working check" (lines 1-7 of
function handle_iptable) then you should just move it inside the
claim_lock "iptables" section and yo
Running "make uninstall" does not remove all installed files, a
situation which might cause link related issues if xen is re-installed
in a different location.
In order to make uninstall correctly remove the files it is best
the process should be done recursively by mirroring each "install"
target
Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons Learned:
Improving Our Release Process and Tooling"):
> [Lars:]
> >Ian: These are most likely software problems, most likely in Xen.
> >ISSUE: nobody wants to debug Windows Heisenbugs
>
> Hmm, I think we believe to have unders
>>> Lars Kurth 07/18/17 2:18 PM >>>
>x86 Heisenbugs in 4.9.0
>---
>- x86 migration Heisenbugs have caused us issues this release cycle: not
>completely understood the issues and hard to debug
>
>Ian: These are most likely software problems, most likely in Xen.
>ISSUE: nobody w
On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote:
> This in turn calls for p2m_alloc_ptp() also being passed the numeric
> level.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
> ---
> Question is whether passing the level to p2m_alloc_ptp() is really all
> that useful: p2m-ept.c's only use pa
> On Jul 27, 2017, at 5:12 PM, Andreas Kinzler wrote:
>
> On Thu, 27 Jul 2017 12:55:14 +0200, George Dunlap
> wrote:
>> For 4.9 we checked in a fix to this problem that would specifically
>> attempt to use the -w option if it was available; see c/s 3d2010f9ff.
>
> Sorry, I think that this pat
From: Jean-Louis Dupond
Date: Thu, 27 Jul 2017 10:21:56 +0200
> Op 2017-06-22 17:16, schreef David Miller:
>> From: Wei Liu
>> Date: Wed, 21 Jun 2017 10:21:22 +0100
>>
>>> Add a flag to indicate if a queue is rate-limited. Test the flag in
>>> NAPI poll handler and avoid rescheduling the queue
On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote:
> Calculate entry PFN and flags just once. Convert the two successive
> main if()-s to and if/elf-if chain. Restrict variable scope where
> reasonable. Take the opportunity and also make the induction variable
> unsigned.
>
> Signed-off-by: Jan B
On Thu, 27 Jul 2017 12:55:14 +0200, George Dunlap
wrote:
For 4.9 we checked in a fix to this problem that would specifically
attempt to use the -w option if it was available; see c/s 3d2010f9ff.
Sorry, I think that this patch is just far to complicated. If you really
want to keep the "iptab
On Tue, Jul 25, 2017 at 07:00:47PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[OSSTEST PATCH v13 19/24] TestSupport: Implement
> target_subunit_cmd a subunit stream parser into substeps"):
> > +# Read chunks of a part
> > +while (<$s
(Adjusting addressees: David is no longer maintaining Xen code, Juergen is)
On 07/27/2017 09:04 AM, shuo.a@intel.com wrote:
> Hi,
> Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost
> interrupt during driver irq_disable/irq_enable.
> There is a pair of irq_disable/enable in
On Thu, Jul 27, 2017 at 04:35:48PM +0100, Andrew Cooper wrote:
> In the future, there will be other policy objects, e.g. MSR.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.
>>> Simon Crowe 07/27/17 2:01 PM >>>
>grub2 requires that the '<' character be escaped which is
>inconvienet for users, provide a more natural specifier.
>
>An example crashkernel argument may be
>
>crashkernel=256M,below=4G
>
>Signed-off-by: Simon Crowe
So why did you resend this? It has been c
On 27/07/17 17:41, Boris Ostrovsky wrote:
> On 07/27/2017 11:31 AM, Juergen Gross wrote:
>> On 27/06/17 19:21, Venu Busireddy wrote:
>>> This patch set is part of a set of patchs that together allow containment
>>> of unrecoverable AER errors from PCIe devices assigned to guests in
>>> passthrough
On 27/07/17 17:37, Boris Ostrovsky wrote:
> On 07/27/2017 11:11 AM, Juergen Gross wrote:
>> The macros for testing domain types are more complicated then they
>> need to. Simplify them.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> include/xen/xen.h | 20 +---
>> 1 file changed, 9
On 07/27/2017 11:31 AM, Juergen Gross wrote:
> On 27/06/17 19:21, Venu Busireddy wrote:
>> This patch set is part of a set of patchs that together allow containment
>> of unrecoverable AER errors from PCIe devices assigned to guests in
>> passthrough mode. The containment is achieved by killing the
In the future, there will be other policy objects, e.g. MSR.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpuid.c| 50 +++--
xen/arch/x86/hvm/hvm.c | 4 ++--
xen/arch/x86/sysctl.c | 8 --
On 07/27/2017 11:11 AM, Juergen Gross wrote:
> The macros for testing domain types are more complicated then they
> need to. Simplify them.
>
> Signed-off-by: Juergen Gross
> ---
> include/xen/xen.h | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/inc
On 27/06/17 19:21, Venu Busireddy wrote:
> This patch set is part of a set of patchs that together allow containment
> of unrecoverable AER errors from PCIe devices assigned to guests in
> passthrough mode. The containment is achieved by killing the guest and
> hiding the device upon receiving the
On 27/07/17 16:20, Boris Ostrovsky wrote:
> On 07/26/2017 07:56 AM, Andrew Cooper wrote:
>> This allows svm_{get,set}_segment_register() to access the user segments by
>> array index, capitalising on x86_seg_* matches the hardware encoding.
> This does read correctly to me, I think some sort of pre
On 07/26/2017 07:56 AM, Andrew Cooper wrote:
> These are entirely unused, and are actually the general x86 register encoding,
> rather than being SVM specific.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
X
On 07/26/2017 07:56 AM, Andrew Cooper wrote:
> This allows svm_{get,set}_segment_register() to access the user segments by
> array index, capitalising on x86_seg_* matches the hardware encoding.
This does read correctly to me, I think some sort of preposition is missing.
"capitalising on x86_seg_
The macros for testing domain types are more complicated then they
need to. Simplify them.
Signed-off-by: Juergen Gross
---
include/xen/xen.h | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 6e8b7fc79801..28c59c
>>> static int pvcalls_front_probe(struct xenbus_device *dev,
>>> const struct xenbus_device_id *id)
>>> {
>>> + int ret = -EFAULT, evtchn, ref = -1, i;
>>> + unsigned int max_page_order, function_calls, len;
>>> + char *versions;
>>> + grant_ref_t gref_head = 0;
On 07/26/2017 08:08 PM, Stefano Stabellini wrote:
> On Wed, 26 Jul 2017, Boris Ostrovsky wrote:
+ count++;
+ else
+ wait_event_interruptible(map->active.inflight_conn_req,
+ pvcalls_front_read_t
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm32/debug-8250.inc | 12 +++--
xen/arch/arm/arm32/debug-exynos4210.inc | 12 +++--
xen/arch/arm/arm32/debug-pl011.inc | 18 +---
xen/arch/arm/arm32/debug-scif.inc | 6 ++-
xen/arch/arm/arm32/debug.S
From: Andrii Anisov
Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
boards, like:
- Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
- M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
- H3ULCB [http://elinux.org/R-Car/Boards/H3SK]
Signed-off-by: Iurii Konovalenko
From: Iurii Konovalenko
Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Andrii Anisov
---
Changes in v2:
- fixed register names in comments and their coding style
---
xen/arch/arm/a
On Thu, Jul 27, 2017 at 02:30:33PM +0300, Oleksandr Andrushchenko wrote:
> ping
>
It is on my list but I'm currently very busy with other urgent things. I
will get to this in due time.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
On Wed, Jul 26, 2017 at 04:41:58PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [OSSTEST PATCH v13 19/24] TestSupport: Implement
> target_subunit_cmd a subunit stream parser into substeps"):
> > I think I start by looking at what kind of characters could be part of
> > type and sub-type
>> This all looks very similar to previous patches. Can it be factored out?
> You are right that the pattern is the same for all commands:
> - get a request
> - fill the request
> - possibly do something else
> - wait
> however each request is different, the struct and fields are different.
> Ther
On 07/17/2017 01:47 PM, Juergen Gross wrote:
> Instead of fiddling with masking the event channels during suspend
> and resume handling let do the irq subsystem do its job. It will do
> the mask and unmask operations as needed.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
(I've
Our remaining arm64 box, laxton1, seems to have died. The symptoms
are similar to those of laxton0. I have asked our contractors to
investigate on-site but I expect they will tell me it's dead.
There are therefore currently no working arm64 test resources in the
Xen Project test facility.
Statu
flight 112341 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112341/
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 13 mig
Hi,
Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost
interrupt during driver irq_disable/irq_enable.
There is a pair of irq_disable/enable in driver. Here is the scenario,
1. irq_disable(dev_irq) -> disable_dynirq -> mask_evtchn(dev_irq channel)
2. dev interrupt raised by HW
flight 112336 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 4 host-install(4)broken REGR. vs. 112276
build-arm64-xsm
Soft-affinity support is usually implemented by means
of a two step "balancing loop", where:
- during the first step, we consider soft-affinity
(if the vcpu has one);
- during the second (if we get to it), we consider
hard-affinity.
In runq_tickle(), we need to do that for checking
whether we
By factoring into one (at the top) all the checks
to see whether current is the idle vcpu, and mark
it as unlikely().
In fact, if current is idle, all the logic for
dealing with yielding, context switching rate
limiting and soft-affinity, is just pure overhead,
and we better rush checking the runq
We want to find the runqueue with the least average load,
and to do that, we scan through all the runqueues.
It is, therefore, enough that, during such scan:
- we identify the runqueue with the least load, among
the ones that have pcpus that are part of the soft
affinity of the vcpu we're call
With context switching ratelimiting enabled, the following
pattern is quite common in a scheduling trace:
0.000845622 |||.x||| d32768v12 csched2:runq_insert d0v13, position 0
0.000845831 |||.x||| d32768v12 csched2:runq_tickle_new d0v13,
processor = 12, credit = 10135529
By, basically, moving all the logic of the function
inside the usual two steps (soft-affinity step and
hard-affinity step) loop.
While there, add two performance counters (in cpu_pick
and in get_fallback_cpu() itself), in order to be able
to tell how frequently it happens that we need to look
for
If, during scheduling, we realize that the current vcpu
is running outside of its own soft-affinity, it would be
preferable to send it somewhere else.
Of course, that may not be possible, and if we're too
strict, we risk having vcpus sit in runqueues, even if
there are idle pcpus (violating work-c
Hello,
Take 2 of soft-affinity for Credit2. Not much changed actually:
- what was patch 1, it went in, so the series is shorter; :-)
- in patch 5 ("xen: credit2: optimize runq_candidate() a little bit"), I
changed things according to George's advice;
- patch 2 ("xen: credit2: soft-affinity aware
grub2 requires that the '<' character be escaped which is
inconvienet for users, provide a more natural specifier.
An example crashkernel argument may be
crashkernel=256M,below=4G
Signed-off-by: Simon Crowe
---
docs/misc/kexec_and_kdump.txt | 8 +++-
docs/misc/xen-command-line.m
flight 112334 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112334/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 4 host-install(4)broken REGR. vs. 111765
build-arm64
When operating on an Intel graphics device, iommu_enable_translation()
panicked (force_iommu==1) or warned (force_iommu==0) about the BIOS if
is_igd_vt_enabled_quirk() returned 0. That's good if the actual BIOS
problem has been detected. But since commit 1463411, returning 0 could
also happen if th
On Wed, 2017-07-26 at 16:39 +0200, Olaf Hering wrote:
> Convert source for xl-numa-placement.7 from markdown to pod.
> This removes the buildtime requirement for pandoc, and subsequently
> the
> need for ghc, in the chain for BuildRequires of xen.rpm.
>
> Signed-off-by: Olaf Hering
>
Reviewed-by:
ping
On 07/18/2017 05:25 PM, Oleksandr Grytsov wrote:
From: Oleksandr Grytsov
Changes since V3:
* libxl__device_add renamed to libxl__device_add_async and reworked
to match the former design;
* libxl__device_add used for devices which don't require updating domain
config but s
On Thu, Jul 27, 2017 at 11:30:11AM +0100, Julien Grall wrote:
>
>
> On 25/07/17 14:25, Wei Liu wrote:
> > Hi all
>
> Hi Wei,
>
> Sorry for the late reply.
>
> > ## Script to generate months update emails
>
> I have an updated script on which include jira ticket, version number:
>
Merged. Th
Hello again,
On Sat, 2017-07-08 at 09:25 +0200, Dario Faggioli wrote:
> On Fri, 2017-07-07 at 17:19 +0100, Julien Grall wrote:
> > I would
> > recommend to stick on credit1 until this bug is fixed (I will mark
> > it
> > as
> > a blocker).
> >
>
> Right. As said, it's on my priority list when
On 27.07.17 13:56, Julien Grall wrote:
Let's rephrase it differently. Is the reserved memory always RAM or
could it be other things?
I think this have to be checked with the DT spec to have an answer.
Well, if your region is cacheable it might be possible to have some
data left in the cache a
flight 112337 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112337/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9cb74c3693f157e7bc00e161734b7d6f0015c9fa
baseline version:
ovmf 1d8701a20e02f8c2c3ca6
On 27/07/17 11:36, Andrii Anisov wrote:
Dear Julien,
On 27.07.17 12:55, Julien Grall wrote:
It really depends on the security impact here. If the reserved memory
is shared with other device, what would be the impact of a domain
using the wrong memory attribute?
I'm sorry, I did not get the
On 07/03/2017 02:07 PM, Wei Liu wrote:
> CC George (author of recent change) and Ian
>
> On Mon, Jul 03, 2017 at 01:30:09PM +0200, Andreas Kinzler wrote:
>> Hello
>>
>> in /etc/xen/scripts/vif-common.sh there is a function handle_iptable.
>> At its start there is a check for a working iptables imp
flight 112332 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112332/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 4 host-install(4)broken REGR. vs. 112286
build-arm64-xsm
On Wed, Jul 26, 2017 at 06:17:06PM +0100, Julien Grall wrote:
> "THE REST" maintainers should always be CCed for any modification that
> don't fall under the responsability of a specific component maintainer.
>
> However, the script get_maintainers.pl will remove "THE REST"
> maintainers as soon a
Dear Julien,
On 27.07.17 12:55, Julien Grall wrote:
It really depends on the security impact here. If the reserved memory
is shared with other device, what would be the impact of a domain
using the wrong memory attribute?
I'm sorry, I did not get the point.
Could you please provide an example
Works for EPAM as well
On 07/27/2017 12:12 AM, Edgar E. Iglesias wrote:
Hi, this time works for me too. I'd like to have a slot to introduce
and discuss the work that Xilinx and Aggios are doing on Power
management for Xen/Arm.
Cheers,
Edgar
Sent from my phone
On Jul 26, 2017 6:59 PM, "Ste
On 25/07/17 14:25, Wei Liu wrote:
> Hi all
Hi Wei,
Sorry for the late reply.
> ## Script to generate months update emails
I have an updated script on which include jira ticket, version number:
#!/bin/bash
# Use ssmtp for simplicity
# ./status-release.sh | formail -f -s /usr/sbin/ssmtp -bm -t
On 27/07/17 10:24, Andrii Anisov wrote:
Hello Julien,
Hi,
On 26.07.17 20:06, Julien Grall wrote:
If you use the memory allocator for those reserved region, then they
should be accounted in the domain memory. If not, then they are
entirely separated and then no need to account them. Just add
Hi Konrad,
On 27/07/17 02:18, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 26, 2017 at 05:59:15PM +0100, Julien Grall wrote:
Hi Konrad,
On 26/07/17 17:54, Konrad Rzeszutek Wilk wrote:
Introduce an earlyprintk configuration of Hikey 960 boards.
..snip..
Would it be possible to update the wiki
Hello Julien,
On 26.07.17 20:06, Julien Grall wrote:
If you use the memory allocator for those reserved region, then they
should be accounted in the domain memory. If not, then they are
entirely separated and then no need to account them. Just add a
separate memory node for it.
I've got your
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of
> Andrew Cooper
>
> On 27/07/2017 07:02, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> >> Sent: Wednesday, July 19, 2017 7:58 PM
> >>
> >> This avoids opencoding the bitmap bases in accessor funct
On 27/07/2017 07:02, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, July 19, 2017 7:58 PM
>>
>> This avoids opencoding the bitmap bases in accessor functions. Introduce a
>> build_assertions() function to check the structure layout against the manu
Hi,
I have read that “From a software standpoint, PCI and PCI Express devices are essentially the same. PCIe devices had the same configuration space, BARs, and (usually) support the same PCI INTx interrupts”.
According to my understanding, PCI and PCIe are different kind of interfaces with differe
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, July 24, 2017 9:48 PM
>
> 1. Remove RDMSRs of VMX MSRs since all values are already available in
>raw_vmx_msr_policy.
> 2. Replace bit operations involving VMX bitmasks with accessing VMX
>features by name and using vm
Op 2017-06-22 17:16, schreef David Miller:
From: Wei Liu
Date: Wed, 21 Jun 2017 10:21:22 +0100
Add a flag to indicate if a queue is rate-limited. Test the flag in
NAPI poll handler and avoid rescheduling the queue if true, otherwise
we risk locking up the host. The rescheduling will be done in
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, July 24, 2017 9:48 PM
>
> Add calculate_vmx_raw_policy() which fills the raw_vmx_msr_policy
> object (the actual contents of H/W VMX MSRs) on the boot CPU. On
> secondary CPUs, this function checks that contents of VMX MSRs ma
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, July 24, 2017 9:48 PM
>
> This structure provides a convenient way of accessing contents of
> VMX MSRs: every bit value is accessible by its name. Bit names match
> existing Xen's definitions as close as possible. The structur
In fact, right now, we read it at every iteration of the loop.
The reason it's done like this is how context switch was handled
on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
However:
1) we don't have IA64 any longer, and all the achitectures that
we do support, are ok wit
Instead of having the CPU where a callback is queued, busy
looping on rcu_pending(), use a timer.
In fact, we let the CPU go idla,e but we program a timer
that will periodically wake it up, for checking whether the
grace period has actually ended.
It is kind of similar to introducing a periodic t
Since commit 964fae8ac ("cpuidle: suspend/resume scheduler
tick timer during cpu idle state entry/exit"), if a scheduler
has a periodic tick timer, we stop it when going idle.
This, however, is only true for x86. Make it true for ARM as
well.
Signed-off-by: Dario Faggioli
---
Cc: Stefano Stabell
If a CPU has a callback queued, it must be ready to invoke
it, as soon as all the other CPUs involved in the grace period
has gone through a quiescent state.
But if we let such CPU go idle, we can't really tell when (if!)
it will realize that it is actually time to invoke the callback.
To solve th
Xen is a tickless (micro-)kernel. This means that, when a CPU
becomes idle, we stop all the activity on it, including any
periodic tick or timer.
When we imported RCU from Linux, Linux (x86) was a ticking
kernel, i.e., there was a periodic timer tick always running,
even on totally idle CPUs. This
Hello everyone,
It took some time, and, honestly, it was a bit of a nightmare, but I think I
did manage to find a way to make our RCU implementation in a status where it
does not only work "by chance" (as it does right now! :-O).
A bit of background in this post:
https://www.mail-archive.com/xe
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, July 24, 2017 9:48 PM
>
> The end goal of having VMX MSRs policy is to be able to manage
> L1 VMX features. This patch series is the first part of this work.
> There is no functional change to what L1 sees in VMX MSRs at this
95 matches
Mail list logo
