branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid xen-boot
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 git://xenbits.xen.org/qemu-xen-tradi
This run is configured for baseline tests only.
flight 68261 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68261/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-start
On Thu, Dec 22, 2016 at 02:41:52PM -0600, Dr. Greg Wettstein wrote:
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in the following
> commit:
>
> ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d
>
> xenbus_client: Extend interface to suppo
flight 103799 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-xl-m
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 20, 2016 6:36 PM
>
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc). Use the
> guaranteed 32-bit underscore prefixed names for now where appro
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 22, 2016 11:37 PM
>
> >>> On 22.12.16 at 16:14, wrote:
> > On 22/12/16 14:58, Jan Beulich wrote:
> > On 22.12.16 at 15:31, wrote:
> >> On 22.12.16 at 14:47, wrote:
> On 22/12/16 08:37, Jan Beulich wrote:
> >>
This run is configured for baseline tests only.
flight 68260 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68260/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-xtf-amd64-amd64-5 20 xtf/test-hvm32-invlpg
On 12/22/2016 06:47 PM, Wei Liu wrote:
Also CC Anthony, who wrote the original code.
On Thu, Dec 22, 2016 at 05:53:07PM +0800, Zhang Chen wrote:
Make select loop more readable.
The behaviour of this function is changed. The changes are not
necessarily wrong, but we need to have clear commit
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 22, 2016 4:37 PM
>
> ... to clarify that the register state does not get altered (behind the
> back of the emulator).
>
> Signed-off-by: Jan Beulich
>
Acked-by: Kevin Tian
__
flight 103801 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103801/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 413535bb33d60417d681725af0274086630e7987
baseline version:
ovmf d0c80b8a2de8ac90f51b8
This run is configured for baseline tests only.
flight 68258 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68258/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install f
flight 103798 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103798/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 103479
Regressions which are
flight 103797 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103797/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103397
test-amd64-i386-xl-qemuu-w
On Thu, Dec 22, 2016 at 2:11 PM, Alistair Francis
wrote:
> On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein wrote:
>> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>>> On 22/12/16 21:41, Alistair Francis wrote:
On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
wrote:
> On Thu, Dec 22, 2
On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein wrote:
> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>> On 22/12/16 21:41, Alistair Francis wrote:
>>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>>> wrote:
On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
wrote:
> On Thu, Dec 2
On 12/22/16 3:47 PM, Andrew Cooper wrote:
> On 22/12/16 21:41, Alistair Francis wrote:
>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>> wrote:
>>> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>>> wrote:
On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
wrote:
> Alistair Fra
On 22/12/16 21:41, Alistair Francis wrote:
On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
wrote:
On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
wrote:
On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson wrote:
Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict
On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
wrote:
> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
> wrote:
>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
>> wrote:
>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded
>>> strict -Werror checking"):
On
On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
wrote:
> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
> wrote:
>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded
>> strict -Werror checking"):
>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote:
On 20.12.16
On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson wrote:
> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded
> strict -Werror checking"):
>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote:
>>> On 20.12.16 at 20:46, wrote:
>> >> Signed-off-by: Alistair Francis
>> >
>> >
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in the following
commit:
ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d
xenbus_client: Extend interface to support multi-page ring
In this commit a pointer to the shared page address was being
flight 103796 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
103782
Regression
Hi my name is Richard and i suscribe to this list but dont know if this list
is for reports bugs.
Tnks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded
strict -Werror checking"):
> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote:
>> On 20.12.16 at 20:46, wrote:
> >> Signed-off-by: Alistair Francis
> >
> > Without some rationale given I don't think such changes are
>
On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich wrote:
On 20.12.16 at 20:46, wrote:
>> Signed-off-by: Alistair Francis
>
> Without some rationale given I don't think such changes are
> acceptable at all. And then, as already pointed out others, the
> use of -Werror is there not just for fun.
Jan Beulich writes ("Re: [PATCH] docs: Clarify scope of reboot= and noreboot
Xen command line options"):
> On 22.12.16 at 16:02, wrote:
> > -Specify the host reboot method.
> > +Specify the host reboot method,
> > +used when Xen crashes.
> > +(This does not affect deliberate reboots initiated by
flight 103795 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103795/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103753
test-armhf-armhf-xl-rtds
The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c | 28
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
ITS device with the same identifier.
Allocate the respective memory and enter each device into a list to
later b
The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-its.c | 41 +++
Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.
Signed-off-by: Andre Przywara
---
Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Signed-off-by:
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.
Signed-off-by: An
To get MSIs from devices forwarded to a CPU, we need to name the device
and its MSIs by mapping them to an ITS.
Since this involves queueing commands to the ITS command queue, we can't
really afford to do this during the guest's runtime, as this would open
up a denial-of-service attack vector.
So w
The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-its.c
The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to ea
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-its.c | 22 ++
xen/arch/arm/vgic-v3.c| 12
xen/include/asm-ar
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 have to save the pending state on the
virtual side.
Signed-of
The MAPD command maps a device by associating a memory region for
storing ITTEs with a certain device ID.
We just store the given guest physical address in the device table.
We don't map the device tables permanently, as their alignment
requirement is only 256 Bytes, thus making mapping of several
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-its.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/xen/arch/arm/vgic-its.c b/x
Parse the DT GIC subnodes 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 iterate over all ITSes.
This introduces an ITS Kconfig option.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Kconf
Create a new file to hold the emulation code for the ITS widget.
For now we 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/Makefi
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to
a guest.
Signed-off-by: Andre Przywara
---
xen/arc
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
In addition this patch introduces the lookup function which translates
a given DeviceID/EventID pair into a pointer to our v
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer to the ITS h/w to create or alter the
LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-
Hi,
this is a reworked version of the Dom0 GICv3-ITS emulation series.
This is still not fully where I want it and has some loose bits and
pieces still, but since there are significant changes in the architecture
I wanted to have an opinion before going ahead and replacing every single
number with
The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-its.c | 30 ++
1 file changed, 30 insertion
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-its.c | 4
xen/arch
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 space to have easy
access.
Signed-off-by: Andre Przywara
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
Each ITS maps a pair of a DeviceID (usually the 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 device and collection tables, which software
has to provide for the ITS to use
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands fo
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can
On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> On 22.12.16 at 17:17, wrote:
>>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>>> Why would Xen need to be abl
Jan Beulich writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in
x86 emulator test harness"):
> On 22.12.16 at 16:10, wrote:
> > I did not find this important build fix for a regression in 4.8.0
> > because:
>
> I wonder why you consider this important - the harness doesn't
> get bu
On 07/12/16 10:22, Jan Beulich wrote:
On 06.12.16 at 17:35, wrote:
On 06/12/16 13:39, Jan Beulich wrote:
@@ -5424,7 +5436,6 @@ x86_emulate(
goto cannot_emulate;
}
- writeback:
This removal highlights that the writeback and no_writeback lables are
incorrectly named.
There i
On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 17:17, wrote:
> > On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> >
> > Why would Xen need to be able to parse the AML that is intended to be
>
flight 103808 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103808/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 22.12.16 at 17:17, wrote:
> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
>> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>
> Why would Xen need to be able to parse the AML that is intended to be
> executed by dom0? I'd think that all the hypervisor would need to do is
On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> On 22.12.16 at 11:43, wrote:
>>> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> Since Xen is the one that sets the local APIC address in the MADT, and it
> al
>>> On 14.12.16 at 05:07, wrote:
> To construct an extendible framework, we need analyze PSR features
> and abstract the common things and feature specific things. Then,
> encapsulate them into different data structures.
>
> By analyzing PSR features, we can get below map.
> +
On 12/20/2016 12:42 PM, Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
Thanks,
Razvan
>>> On 14.12.16 at 05:07, wrote:
> The current cache allocation codes in psr.c do not consider
> future features addition and are not friendly to extend.
>
> To make psr.c be more flexible to add new features and fulfill
> the program principle, open for extension but closed for
> modification, w
On 12/22/2016 10:55 AM, Juergen Gross wrote:
> On 22/12/16 16:49, Boris Ostrovsky wrote:
>> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>>> When the xenbus driver does some special handling for a Xenstore
>>> command any error condition related to the command should be returned
>>> via an error re
On 22/12/16 16:49, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When the xenbus driver does some special handling for a Xenstore
>> command any error condition related to the command should be returned
>> via an error response instead of letting the related write operati
On 22/12/16 16:38, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When accessing Xenstore in a transaction the user is specifying a
>> transaction id which he normally obtained from Xenstore when starting
>> the transaction. Xenstore is validating a transaction id against
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of
> xs_input_avail(). Remove it.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@li
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When the xenbus driver does some special handling for a Xenstore
> command any error condition related to the command should be returned
> via an error response instead of letting the related write operation
> fail. Otherwise the user land handler migh
On 12/20/16 1:47 PM, Alistair Francis wrote:
> To avoid build errors related to missing file 'sys/sysctl.h' by removing
> the #include statement.
>
> Signed-off-by: Alistair Francis
> ---
> tools/blktap2/drivers/block-remus.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/blktap2
On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu wrote:
> On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote:
>> To avoid build errors related to missing file 'sys/sysctl.h' by removing
>> the #include statement.
>>
>> Signed-off-by: Alistair Francis
>
> I can find this in Linux. Maybe this
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When accessing Xenstore in a transaction the user is specifying a
> transaction id which he normally obtained from Xenstore when starting
> the transaction. Xenstore is validating a transaction id against all
> known transaction ids of the connection t
>>> On 22.12.16 at 16:14, wrote:
> On 22/12/16 14:58, Jan Beulich wrote:
> On 22.12.16 at 15:31, wrote:
>> On 22.12.16 at 14:47, wrote:
On 22/12/16 08:37, Jan Beulich wrote:
> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
> determine whether to install th
>>> On 22.12.16 at 16:28, wrote:
> On 12/20/16 3:37 AM, Anshul Makkar wrote:
>> On 20/12/2016 04:03, Doug Goldstein wrote:
>>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>> During guest migrate
>>> On 22.12.16 at 16:02, wrote:
> @@ -1356,7 +1357,9 @@ The following resources are available:
>
> > Default: `0`
>
> -Specify the host reboot method.
> +Specify the host reboot method,
> +used when Xen crashes.
> +(This does not affect deliberate reboots initiated by dom0.)
This should be
On 12/20/16 3:37 AM, Anshul Makkar wrote:
> On 20/12/2016 04:03, Doug Goldstein wrote:
>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
>>> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
On 12/12/2016 09:00 AM, Anshul Makkar wrote:
> During guest migrate allow permission to prevent
> spurio
>>> On 22.12.16 at 16:10, wrote:
> I did not find this important build fix for a regression in 4.8.0
> because:
I wonder why you consider this important - the harness doesn't
get built by default, and is of little use for other than smoke
testing a limited set of changes to the insn emulator.
>
Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package.
---
Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.
To Do:
- Have configure detect golang bindings properly
CC: xen-devel
CC: Ian Jackson
Andrew Cooper writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in
x86 emulator test harness"):
> On 22/12/16 14:58, Ian Jackson wrote:
> > "x86emul: in_longmode() should not ignore ->read_msr() errors" aka
> > c/s 122dd9575c7a introduced a use of unlikely() in
> > xen/arch/x86/x86_em
On 22/12/16 14:58, Jan Beulich wrote:
On 22.12.16 at 15:31, wrote:
On 22.12.16 at 14:47, wrote:
On 22/12/16 08:37, Jan Beulich wrote:
Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.
Signed-off-by: Jan Beulich
I am
Signed-off-by: Ian Jackson
CC: Jan Beulich
---
docs/misc/xen-command-line.markdown | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 0138978..68c81e6 100644
--- a/docs/misc/xen-command-line.mar
On 22/12/16 14:58, Ian Jackson wrote:
"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.
I think this is probably intentional and fine. However, there is no
definition of unlikely in the x
"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.
I think this is probably intentional and fine. However, there is no
definition of unlikely in the x86 emulator test harness, under tools.
>>> On 22.12.16 at 15:31, wrote:
On 22.12.16 at 14:47, wrote:
>> On 22/12/16 08:37, Jan Beulich wrote:
>>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>>> determine whether to install the hook in the first place.
>>>
>>> Signed-off-by: Jan Beulich
>>
>> I am not so su
>>> On 22.12.16 at 14:47, wrote:
> Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
> 103788: regressions - trouble: broken/fail/pass)"):
>> On 22.12.16 at 13:19, wrote:
>> > Perhaps it would be worth telling Xen not to reboot on crash...
>>
>> I think that's worth giv
>>> On 07.12.16 at 16:57, wrote:
> efi/buildid.o: file not recognized: File format is ambiguous
> efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
Just fyi: After some analysis of the binutils sources I have come to
the conclusion that this needs help from the binutils folks. I've
flight 103806 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 68259 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68259/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68223
jobs:
build-amd64 pass
build-armh
>>> On 22.12.16 at 14:47, wrote:
> On 22/12/16 08:37, Jan Beulich wrote:
>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>> determine whether to install the hook in the first place.
>>
>> Signed-off-by: Jan Beulich
>
> I am not so sure about this.
>
> vmfunc is reachable in
flight 103792 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103792/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-13 host-install(3)broken REGR. vs. 10
On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> Move the __jump_table from the a custom section solution
> to a generic solution, this avoiding extra vmlinux.lds.h
> customizations.
>
> This also demos the use of the .data linker table and of
> the shared asm call push_section_tbl().
On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> A linker table is a data structure that is stitched together from
> items
> in multiple object files. Linux has historically implicitly used
> linker
> tables for ages, however they were all built in an adhoc manner which
> requires link
Sander Eikelenboom writes ("Re: [Xen-devel] Xenstore watch interface in the
kernel"):
> Something I did ran into while trying to use xenstore, was that the
> callbacks don't give back the previous and current value.
Others have replied to this, and I agree with them, but: this makes me
think you
Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
103788: regressions - trouble: broken/fail/pass)"):
> On 22.12.16 at 13:19, wrote:
> > Perhaps it would be worth telling Xen not to reboot on crash...
>
> I think that's worth giving a try (I assume that some timeout will
On 22/12/16 08:37, Jan Beulich wrote:
Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.
Signed-off-by: Jan Beulich
I am not so sure about this.
vmfunc is reachable in the instruction emulator on hardware which
doesn't
On 22/12/16 08:36, Jan Beulich wrote:
... to clarify that the register state does not get altered (behind the
back of the emulator).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://l
On 22/12/16 12:59, Juergen Gross wrote:
On 22/12/16 13:49, Sander Eikelenboom wrote:
Thursday, December 22, 2016, 1:22:06 PM, you wrote:
Juergen Gross writes ("Xenstore watch interface in the kernel"):
While working on the Linux xenbus kernel driver I stumbled over a rather
strange interface:
On December 22, 2016 2:21:26 AM EST, Oleksandr Andrushchenko
wrote:
>Hi, Konrad!
>
>I see no comments for almost 3 weeks now, so
>probably there are no objections against this protocol.
>Can we please move on on this?
Sorry, I had been busy with internal high priority items. Let me take a look a
On 22/12/16 13:49, Sander Eikelenboom wrote:
>
> Thursday, December 22, 2016, 1:22:06 PM, you wrote:
>
>> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>>> While working on the Linux xenbus kernel driver I stumbled over a rather
>>> strange interface: a Xenstore watch event is
Thursday, December 22, 2016, 1:22:06 PM, you wrote:
> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>> While working on the Linux xenbus kernel driver I stumbled over a rather
>> strange interface: a Xenstore watch event is delivered via a callback
>> defined as:
>>
>> void (*
1 - 100 of 156 matches
Mail list logo
