Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.11b-rc6-tag
It contains a fix for error path cleanup in the xenbus handler.
Thanks.
Juergen
drivers/xen/xenbus/xenbus_dev_frontend.c | 4 +++-
1 file changed, 3 insertions(+), 1
On 17-04-06 08:08:11, Jan Beulich wrote:
> >>> On 06.04.17 at 13:13, wrote:
> > On 17-04-06 02:40:01, Jan Beulich wrote:
> >> >>> On 06.04.17 at 08:10, wrote:
> >> > On 17-04-05 09:51:44, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53, wrote:
> >
> > [...]
> >> >> > --- a/xen/arch/x86/psr.
On 17-04-06 08:04:16, Jan Beulich wrote:
> >>> On 06.04.17 at 13:16, wrote:
> > On 17-04-06 02:36:19, Jan Beulich wrote:
> >> >>> On 06.04.17 at 08:05, wrote:
> >> > On 17-04-05 09:37:44, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53, wrote:
> >> >> > @@ -183,6 +187,22 @@ static bool feat_
On 17-04-06 08:02:15, Jan Beulich wrote:
> >>> On 06.04.17 at 12:02, wrote:
> > On 17-04-06 03:34:27, Jan Beulich wrote:
> >> >>> On 06.04.17 at 11:22, wrote:
> >> > On 17-04-06 02:32:04, Jan Beulich wrote:
> >> >> >>> On 06.04.17 at 07:49, wrote:
> >> >> > On 17-04-05 09:10:58, Jan Beulich wrot
This run is configured for baseline tests only.
flight 71158 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71158/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-
flight 107232 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 106822
test-amd64-amd6
flight 107234 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107234/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3)broken REGR. vs. 10
flight 107257 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107257/
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
build-arm64-pvops 5 ker
It being very very basic, also means this scheduler does
not need much support at the tools level (for now).
Basically, just the definition of the symbol of the
scheduler itself and a couple of stubs.
Signed-off-by: Dario Faggioli
Acked-by: Wei Liu
Acked-by: Stefano Stabellini
---
Cc: Ian Jack
In cases where one is absolutely sure that there will be
less vCPUs than pCPUs, having to pay the cose, mostly in
terms of overhead, of an advanced scheduler may be not
desirable.
The simple scheduler implemented here could be a solution.
Here how it works:
- each vCPU is statically assigned to a
Clarify and enforce (with ASSERTs) when the function
is called on the idle domain, and explain in comments
what it means and when it is ok to do so.
While there, change the name of the function to a more
self-explanatory one, and do the same to VCPU2OP.
Signed-off-by: Dario Faggioli
---
Cc: Geor
As a (rudimental) way of directing and affecting the
placement logic implemented by the scheduler, support
vCPU hard affinity.
Basically, a vCPU will now be assigned only to a pCPU
that is part of its own hard affinity. If such pCPU(s)
is (are) busy, the vCPU will wait, like it happens
when there
When a pCPU is added to a cpupool, the pool's scheduler
should immediately run on it so, for instance, any runnable
but not running vCPU can start executing there.
This currently does not happen. Make it happen by raising
the scheduler softirq directly from the function that
sets up the new schedu
Hello,
here it comes v2 of this series about the 'null' scheduler.
v1, with much details about the idea and the goal of this scheduler is here:
https://lists.xen.org/archives/html/xen-devel/2017-03/msg02316.html
In this version, I'm basically addressing the review comments I received.
There ar
On Thu, 2017-04-06 at 13:06 +0200, Juergen Gross wrote:
> On 06/04/17 12:59, Dario Faggioli wrote:
> > Maybe:
> >
> > domain_scheduler()
> > vcpu_scheduler()
> >
> > or
> >
> > dom_scheduler()
> > vcpu_scheduler()
> >
> > Or, also trading 'scheduler' for 'ops':
> >
> > dom_ops()
> > vcpu_ops()
flight 107233 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107233/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 107185
test-armhf-armhf-libvirt
Hi Stefano,
I have used attached bin2c.c convert the contents of .config file to hex.
(echo "static const char xen_config_data[] __attribute__((used)) =
./bin2c.o xen_config.h
the above command will generate the header file which will contain the
contents of config file in hex form.
i wrote a
Hi Stefano,
On 04/05/2017 09:28 PM, Stefano Stabellini wrote:
When an irq migration is already in progress, but not yet completed
(GIC_IRQ_GUEST_MIGRATING is set), refuse any other irq migration
requests for the same irq.
This patch implements this approach by returning success or failure from
Hi Vijay,
On 04/06/2017 11:13 AM, vijay.kil...@gmail.com wrote:
[...]
On ARM64 this arch helper will return true, because currently all RAM
is direct mapped in Xen.
On ARM32, Only a limited amount of RAM, called xenheap, is always mapped
NIT: s/Only/only/
and DIRECTMAP_VIRT region is not m
On 06/04/17 12:42, Julien Grall wrote:
> Hi,
>
> On 06/04/17 11:21, Andre Przywara wrote:
>> Hi,
>>
>> On 06/04/17 02:04, Stefano Stabellini wrote:
>>> On Thu, 6 Apr 2017, Andre Przywara wrote:
To let a guest know about the availability of virtual LPIs, set the
respective bits in the vir
Hi Andre,
On 04/06/2017 12:19 AM, Andre Przywara wrote:
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap
This run is configured for baseline tests only.
flight 71155 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debia
Hi Andre,
Another thing I missed.
On 04/06/2017 12:19 AM, Andre Przywara wrote:
+case VREG64(GITS_BASER0): /* device table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(&its->its_lock);
+
+/*
+ * Changing base register
Hi Andre,
On 04/06/2017 11:22 PM, André Przywara wrote:
On 06/04/17 22:43, Julien Grall wrote:
On 04/06/2017 12:19 AM, Andre Przywara wrote:
+static int vgic_v3_its_mmio_read(struct vcpu *v, mmio_info_t *info,
+ register_t *r, void *priv)
+{
+struct virt_its
On 06/04/17 23:19, Julien Grall wrote:
> Hi Andre,
>
> On 04/06/2017 12:18 AM, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (for instance derived from a PCI
>> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
>> pair of LPI number and collection ID, which points
Hi Andre,
On 04/06/2017 12:19 AM, Andre Przywara wrote:
+case VREG64(GITS_BASER0): /* device table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(&its->its_lock);
+
+/*
+ * Changing base registers with the ITS enabled is
On 06/04/17 22:43, Julien Grall wrote:
Salut Julien,
> On 04/06/2017 12:19 AM, Andre Przywara wrote:
>> Emulate the memory mapped ITS registers and provide a stub to introduce
>> the ITS command handling framework (but without actually emulating any
>> commands at this time).
>>
>> Signed-off-by:
Hi Andre,
On 04/06/2017 12:18 AM, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
pair of LPI number and collection ID, which points to the target CPU.
This mapping is stored in the dev
This run is configured for baseline tests only.
flight 71157 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71157/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 80c4b236389fb246dfd5c4f28e625600974a575d
baseline v
Hi Andre,
On 04/06/2017 12:19 AM, Andre Przywara wrote:
Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c|
On Thu, 6 Apr 2017, Volodymyr Babchuk wrote:
> Hello all,
>
> I want to discuss EL0 (native) applications for XEN. This will be relatively
> long e-mail with requirements, proposed design and my PoC results.
>
> So, why we want XEN native applications in the first place? I see the
> following
>
flight 71156 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71156/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64-pvops 2 hosts-allocate broken never pass
build-arm64
Hi Andre,
On 04/06/2017 12:19 AM, Andre Przywara wrote:
If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but hav
On Thu, 6 Apr 2017, Andre Przywara wrote:
> On 06/04/17 00:58, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> If a guest disables an LPI, we do not forward this to the associated
> >> host LPI to avoid queueing commands to the host ITS command queue.
> >> So it may hap
Hi Oleksandr,
Please try to configure the mail client to quote with '>'. Using tab for
quoting make it quite difficult to follow.
On 04/06/2017 09:36 PM, Oleksandr Tyshchenko wrote:
6 апр. 2017 г. 22:22 пользователь "Julien Grall" mailto:julien.gr...@arm.com>> написал:
If the IOMMU is not
6 апр. 2017 г. 22:22 пользователь "Julien Grall"
написал:
Hi Oleksandr,
Hi Julien.
On 04/06/2017 07:59 PM, Oleksandr Tyshchenko wrote:
> Hi, guys.
>
> Seems, it was only my fault. The issue wasn't exactly in shattering,
> the shattering just increased probability for IOMMU page faults to
> o
Hi Andre,
On 04/06/2017 12:19 AM, Andre Przywara wrote:
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address
On Thu, 6 Apr 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 04/06/2017 08:47 PM, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Julien Grall wrote:
> > > On 04/06/2017 07:47 PM, Stefano Stabellini wrote:
> > > > On Thu, 6 Apr 2017, Andre Przywara wrote:
> > > > > > > unsigned long status;
Hello all,
I want to discuss EL0 (native) applications for XEN. This will be relatively
long e-mail with requirements, proposed design and my PoC results.
So, why we want XEN native applications in the first place? I see the following
reasons:
1. Isolation. I see XEN as a sort of micro-kernel, s
flight 107221 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107221/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Hi Stefano,
On 04/06/2017 08:47 PM, Stefano Stabellini wrote:
On Thu, 6 Apr 2017, Julien Grall wrote:
On 04/06/2017 07:47 PM, Stefano Stabellini wrote:
On Thu, 6 Apr 2017, Andre Przywara wrote:
unsigned long status;
struct irq_desc *desc; /* only set it the irq corresponds to a
phys
On Thu, Apr 06, 2017 at 03:57:06PM +0100, George Dunlap wrote:
> Signed-off-by: George Dunlap
> ---
> Andrew Cooper
> Ian Jackson
> Jan Beulich
> Konrad Rzeszutek Wilk
> Stefano Stabellini
> Tim Deegan
> Wei Liu
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff -
From: Chris Patterson
Several Tegra hardware devices, and the Tegra device tree, expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the hardware domain.
As the Tegra LIC provides the ability
From: Chris Patterson
Tegra boards feature a NS16550-compatible serial mapped into the MMIO
space. Add support for its use both as a full-featured serial port and
as an earlyprintk driver.
This patch adds a quirk for platforms, such as the Tegra, which require
require the NS16550 Rx timeout inte
From: "Chris Patterson"
Some common platforms (e.g. Tegra) have non-traditional IRQ controllers
that must be programmed in addition to their primary GICs-- and which
can come in unusual topologies. Device trees for targets that feature
these controllers often deviate from the conventions that Xen
The attached patch-set adds support for 32-bit and 64-bit Tegra SoCs; including
support for the Jetson TK1 and Jetson TX1 boards, as well as the Pixel C tablet.
Previous revisions have been tested against the TK1, TX1, and Pixel C. This
current patch set has only been tested against the TX1 due to
On Thu, 6 Apr 2017, Julien Grall wrote:
> On 04/06/2017 07:47 PM, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> > > > > unsigned long status;
> > > > > struct irq_desc *desc; /* only set it the irq corresponds to a
> > > > > physical irq */
> > > > > unsig
From: "Chris Patterson"
Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be handling their inter
From: "Chris Patterson"
The addition of new IRQ-related platform hooks now allow platforms to
perform platform-specific interrupt logic, such as allowing virtualization
of platform-specific interrupt controller hardware.
This commit adds the ability for the platform to identify the domain
a give
From: "Chris Patterson"
Currently, the interrupt parent is left undefined during creation in
make_gic_node(). In cases where a non-GIC interrupt controller is present,
this can lead to incorrect assignment of interrupt parents.
On the Tegra, the gic's interrupt parent is set to itself:
flight 107252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107252/
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
build-arm64-pvops 5 ker
Hi Oleksandr,
On 04/06/2017 07:59 PM, Oleksandr Tyshchenko wrote:
Hi, guys.
Seems, it was only my fault. The issue wasn't exactly in shattering,
the shattering just increased probability for IOMMU page faults to
occur. I didn't do clean_dcache for the page table entry after
updating it. So, wit
Hi Stefano,
On 04/06/2017 07:47 PM, Stefano Stabellini wrote:
On Thu, 6 Apr 2017, Andre Przywara wrote:
unsigned long status;
struct irq_desc *desc; /* only set it the irq corresponds to a physical
irq */
unsigned int irq;
#define GIC_INVALID_LR (uint8_t)~0
uint8_t
On Wed, 2017-04-05 at 16:43 -0700, Heather Booker wrote:
> Hi!
>
> I'd love to work on the Code Review Dashboard project for this round
> of Outreachy.
Great!!
> Are the steps outlined
> here http://markmail.org/message/7adkmords3imkswd still the first
> contribution you'd like to see?
Yes.
>
Hi,
On 06/04/17 00:58, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> If a guest disables an LPI, we do not forward this to the associated
>> host LPI to avoid queueing commands to the host ITS command queue.
>> So it may happen that an LPI fires nevertheless on the host.
On Tue, Apr 4, 2017 at 12:28 PM, Oleksandr Tyshchenko
wrote:
> Hi, Stefano.
>
> On Mon, Apr 3, 2017 at 11:33 PM, Stefano Stabellini
> wrote:
>> On Mon, 3 Apr 2017, Oleksandr Tyshchenko wrote:
>>> On Mon, Apr 3, 2017 at 9:06 PM, Julien Grall wrote:
>>> > Hi Andrew,
>>> >
>>> >
>>> > On 03/04/17 1
Hi,
On 06/04/17 00:26, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> Parse the GIC subnodes in the device tree to find every ITS MSI controller
>> the hardware offers. Store that information in a list to both propagate
>> all of them later to Dom0, but also to be able to
On Thu, 6 Apr 2017, Andre Przywara wrote:
> Hi Stefano,
>
> thanks for spending your brain cells on this nasty code.
>
> ...
>
> On 06/04/17 00:45, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> Upon receiving an LPI on the host, we need to find the right VCPU and
>
On 06/04/17 19:33, Wei Liu wrote:
> The check builds header file as if it is a C file. Clang doesn't like
> the idea of having dead code in C file. The check as-is fails on Clang
> with unused function warnings.
>
> Use a dummy file like the C++ header check to fix this.
>
> Signed-off-by: Wei Liu
The check builds header file as if it is a C file. Clang doesn't like
the idea of having dead code in C file. The check as-is fails on Clang
with unused function warnings.
Use a dummy file like the C++ header check to fix this.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc:
On 07/03/17 15:38, Ian Jackson wrote:
> Andrew Cooper writes ("[OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner
> returning CRASH"):
>> ./xtf-runner wants to distinguish between a clean and unclean exits of the
>> test. OSSTest doesn't care, so map unclean exit to failure.
> Acked-by: Ian Jack
Hi Andre,
On 06/04/17 00:19, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 270a136..f4d7949 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
return 0;
}
+void gicv2_do_LPI(unsi
Hi Andre,
On 06/04/17 17:10, Andre Przywara wrote:
On 06/04/17 16:34, Julien Grall wrote:
+if ( ret )
+{
+do {
+i--;
+gicv3_free_host_lpi_block(dev->host_lpi_blocks[i]);
+if ( i == 0 )
+break;
+} while (1);
This could
On Thu, 6 Apr 2017, Andre Przywara wrote:
> On 06/04/17 01:47, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> The MOVI command moves the interrupt affinity from one redistributor
> >> (read: VCPU) to another.
> >> For now migration of "live" LPIs is not yet implemented
On Thu, Apr 06, 2017 at 09:51:32AM -0700, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Jan Beulich wrote:
> > >>> On 06.04.17 at 14:54, wrote:
> > > --- a/xen/include/Makefile
> > > +++ b/xen/include/Makefile
> > > @@ -111,7 +111,7 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > > headers9
Hi all
It looks like there a lot of patch waiting on the mailing list for a
release-ack.
To simplify things, I will forgo the requirement of release-ack until
the code freeze and leave the call to the committers.
Cheers,
--
Julien Grall
___
Xen-
Hi Stefano,
thanks for spending your brain cells on this nasty code.
...
On 06/04/17 00:45, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> Upon receiving an LPI on the host, we need to find the right VCPU and
>> virtual IRQ number to get this IRQ injected.
>> Iterate ou
On 06/04/17 18:43, Daniel Kiper wrote:
> On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:
>> On 06/04/17 18:06, Daniel Kiper wrote:
>>> Hi Julien,
>>>
>>> On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
Hi Daniel,
On 06/04/17 16:20, Daniel Kiper wrote:
>>>
We want things like build jobs to be able to download things via
https. But we want them to be cached. To this end, we are having our
squid treat CONNECT as a request to MITM the TLS connection.
But this means that clients will see squid's cert, not the real one.
So placate them by installing th
Signed-off-by: Ian Jackson
---
production-config | 25 +
1 file changed, 25 insertions(+)
diff --git a/production-config b/production-config
index a95e243..07cf5a6 100644
--- a/production-config
+++ b/production-config
@@ -140,3 +140,28 @@ ssh-rsa
B3NzaC1yc2EDAQA
Clients including curl honour https_proxy (not http_proxy) in the
environment for https:// urls.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ac9726c..4ced6c0 100644
No overall functional change, other than slight syntax changes to
generated shell runes.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6ca8076
And rename it to pv_inject_guest_trap. It will be needed later when some
PV specific code is moved.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 61 ++--
xen/include/asm-x86/domain.h | 12 +
2 files changed, 37 i
Delete all trailing white spaces. Replace bool_t with bool.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/Makefile| 1 +
xen/arch/x86/pv/x86_64/Makefile | 1 +
xen/arch/x86/{ => pv}/x86_64/compat/traps.c | 0
xen/arch/x86/pv/x86_64/traps.c | 398
xen/arch/x
This series splits PV code related to trap handling to files under pv
directory.
The final two patches are clean-up that seem easy enough to do.
Wei Liu (7):
x86: move x86_64/entry.S to pv directory
x86: move x86_64/compat/entry.S to pv/compat
x86/traps: lift do_guest_trap to traps.h
x86/
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 0f09d858f6..64f2ffbd69 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/trap
That file contains 32 bit PV guest entry points.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/Makefile| 2 ++
xen/arch/x86/{x86_64 => pv}/compat/Makefile | 0
xen/arch/x86/{x86_64 => pv}/compat/entry.S | 0
xen/arch/x86/x86_64/Makefile| 2
That file contains 64 bit PV guest entry points.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/Makefile| 1 +
xen/arch/x86/{x86_64 => pv}/entry.S | 0
xen/arch/x86/x86_64/Makefile| 1 -
3 files changed, 1 insertion(+), 1 deletion(-)
rename xen/arch/x86/{x
I started off my attempt to figure out what's going on with the centos-virt
group as that is the Xen entry point I use for server. It was recommended
to me to put my issue here. This is the beginging of the thread:
https://lists.centos.org/pipermail/centos-virt/2017-March/005411.html
George suggest
On 06/04/17 17:42, Stefano Stabellini wrote:
On Thu, 6 Apr 2017, Julien Grall wrote:
Hi Stefano,
On 06/04/17 00:41, Stefano Stabellini wrote:
+/* An Interrupt Translation Table needs to be 256-byte aligned. */
+itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
+if ( !itt_a
flight 107245 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107245/
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
build-arm64-pvops 5 ker
flight 107219 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107219/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107196
test-amd64-amd64-xl-qemuu-
On Thu, 6 Apr 2017, Jan Beulich wrote:
> >>> On 06.04.17 at 14:54, wrote:
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -111,7 +111,7 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> > rm -f $@.new
> > $(foreach i,
On 06/04/17 16:53, Yu Zhang wrote:
> After an ioreq server has unmapped, the remaining p2m_ioreq_server
> entries need to be reset back to p2m_ram_rw. This patch does this
> asynchronously with the current p2m_change_entry_type_global()
> interface.
>
> New field entry_count is introduced in struc
On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:
> On 06/04/17 18:06, Daniel Kiper wrote:
> > Hi Julien,
> >
> > On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> >> Hi Daniel,
> >>
> >> On 06/04/17 16:20, Daniel Kiper wrote:
> >>> On Thu, Apr 06, 2017 at 04:38:24PM +020
On Thu, 6 Apr 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 06/04/17 00:41, Stefano Stabellini wrote:
> > > +/* An Interrupt Translation Table needs to be 256-byte aligned. */
> > > +itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
> > > +if ( !itt_addr )
> > > +goto o
On 06/04/17 15:14, Jan Beulich wrote:
On 06.04.17 at 11:47, wrote:
>> On 06/04/17 07:58, Jan Beulich wrote:
>> On 05.04.17 at 18:24, wrote:
On 03/04/17 11:10, Jan Beulich wrote:
On 31.03.17 at 21:50, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
Anthony PERARD writes ("[OSSTEST PATCH v9 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian
There are some oddities to take care of here - see the code comment.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1818,11 +1818,24 @@ protmode_load_seg(
if ( !is_x86_user_segment(seg) )
{
-int lm = (d
On 06/04/17 18:06, Daniel Kiper wrote:
> Hi Julien,
>
> On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
>> Hi Daniel,
>>
>> On 06/04/17 16:20, Daniel Kiper wrote:
>>> On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
On 06/04/17 16:27, Daniel Kiper wrote:
> On T
flight 107213 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 9 xen-boot/src_hostfail REGR. vs. 107169
test-amd64-amd64-pai
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is m
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.
New field entry_count is introduced in struct p2m_domain, to record
the number of p2m_ioreq
In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.
For p2m_ioreq_server pages, current ioreq server only forwards
the write operati
Previously, p2m_ioreq_server is used to write-protect guest ram
pages, which are tracked with ioreq server's rangeset. However,
number of ram pages to be tracked may exceed the upper limit of
rangeset.
Now, a new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added
to let one ioreq server claim/
A new device model wrapper is added for the newly introduced
DMOP - XEN_DMOP_map_mem_type_to_ioreq_server.
Since currently this DMOP only supports the emulation of write
operations, attempts to trigger the DMOP with values other than
XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server)
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation proces
XenGT leverages ioreq server to track and forward the accesses to GPU
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O
Hi,
On 06/04/17 16:34, Julien Grall wrote:
> Hi Andre,
>
> On 06/04/17 00:19, Andre Przywara wrote:
>> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
>> those IDs, which we directly pass on to the host.
>> For this we have to map each device that Dom0 may request to a host
>
1 - 100 of 255 matches
Mail list logo
