On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend d
Hi, Dmitry!
On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.
Signed-off-by: Oleksandr Andrushchenko
>>> On 20.04.17 at 22:40, wrote:
> --- a/arch/x86/include/arch/msr-index.h
> +++ b/arch/x86/include/arch/msr-index.h
> @@ -38,6 +38,17 @@
> #define MSR_GS_BASE 0xc101
> #define MSR_SHADOW_GS_BASE 0xc102
>
> +#define MSR_IA32_PMC(n) (0x00
>>> On 20.04.17 at 04:14, wrote:
> On 17-04-19 03:00:29, Jan Beulich wrote:
>> >>> On 19.04.17 at 10:22, wrote:
>> > On 17-04-18 05:46:43, Jan Beulich wrote:
>> >> >>> On 18.04.17 at 12:55, wrote:
>> >> > I made a test patch based on v10 and attached it in mail. Could you
>> >> > please
>> >> >
>>> On 20.04.17 at 18:52, wrote:
> So to summarise:
>
> On item 1: it appears that you are looking for a some more justification why
> some of the changes were made, maybe with a rationale for some of the choices
> that were made. Given that this is quite a complex series which has diverged
>
On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Xen input para-virtual protocol defines string constants
> used by both back and frontend. Use those instead of
> explicit strings in the frontend driver.
>
> Signed-off-by: Oleksandr And
Hi Oleksandr,
On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Extend xen_kbdfront to provide multi-touch support
> to unprivileged domains.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/input/misc/xen-kbdfront.c | 142
This run is configured for baseline tests only.
flight 71212 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71212/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21e359dccab7f3cd7b527721be042d034349417d
baseline v
> If this reaction of mine is not acceptable, all I can do is refrain
> from further looking at this series. And Yi, I certainly apologize
> for perhaps not doing these reviews wholeheartedly, since -
> as also expressed before - I continue to not really view this as
> very important functionality.
This run is configured for baseline tests only.
flight 71210 linux-arm-xen real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71210/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-midway 15 guest-start/de
flight 107560 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107560/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107528
test-amd64-i386-xl-qemuu-wi
On Thu, Apr 20, 2017 at 12:05 PM, Eric Blake wrote:
> On 04/20/2017 11:18 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>>>
No objection to Alistair's idea to turn this into an enumeration.
>>>
>>> Question - should the enum b
flight 107564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107564/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21e359dccab7f3cd7b527721be042d034349417d
baseline version:
ovmf 4395f82e7f81f5215e52f
On Thu, 20 Apr 2017, Julien Grall wrote:
> == Cross-compiling ==
>
> Anastasios: We are looking at support Xen in Buildroot. The use case is a
> small initramfs.
>
> Potential task: Keep Xen updated on buildroot. Anastasios could help on that.
>
> Stefano: Xen is compiling fine with Yocto.
>
>
flight 107558 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Regressions which are
This patch adds Intel PMU MSR addresses as macros for VPMU testing
Signed-off-by: Mohit Gambhir
---
arch/x86/include/arch/msr-index.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/include/arch/msr-index.h
b/arch/x86/include/arch/msr-index.h
index 2e90079..7df9097 100
This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.
The tests are curren
This patch series adds tests to validate VPMU functionality on x86. The tests
write and read PMU MSRs to make sure that that they have been exposed
correctly.
The ultimate goal is to address security vulnerabilities, if any, that are
vaguely mentioned in XSA-163 and make VPMU available to guests w
On 04/19/2017 05:22 PM, Eric Blake wrote:
> Libvirt would like to be able to distinguish between a SHUTDOWN
> event triggered solely by guest request and one triggered by a
> SIGTERM or other action on the host. qemu_kill_report() is
> already able to tell whether a shutdown was triggered by a hos
Hi Stefano,
On 12 April 2017 at 22:17, Stefano Stabellini wrote:
> On Wed, 12 Apr 2017, Dario Faggioli wrote:
>> On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
>> > On Fri, 7 Apr 2017, Stefano Stabellini wrote:
>> > >
>> > > This is the most difficult problem that we need to solve a
flight 107569 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107569/
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 12 mig
flight 107557 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107557/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in
107542 pass in 107557
test-armhf-a
On 04/20/2017 11:18 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>>
>>>
>>> No objection to Alistair's idea to turn this into an enumeration.
>>
>> Question - should the enum be more than just 'guest' and 'host'? For
>> example, my patch
flight 107555 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107555/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 04/20/2017 11:12 AM, Markus Armbruster wrote:
>>> Well technically /usr/sbin/halt just terminates all processes / kernel and
>>> halts CPUs, but the virtual machine is still active (and a 'reset' in the
>>> monitor can start it again. /usr/sbin/poweroff is what actually does the
>>> ACPI powero
Hi,
On 18/04/17 19:51, Juergen Gross wrote:
On 18/04/17 20:46, Stefano Stabellini wrote:
On Tue, 18 Apr 2017, Juergen Gross wrote:
On 18/04/17 20:37, Stefano Stabellini wrote:
On Thu, 6 Apr 2017, Juergen Gross wrote:
On 06/04/17 18:43, Daniel Kiper wrote:
On Thu, Apr 06, 2017 at 06:22:44PM
On Thu, 20 Apr 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 20 April 2017 00:02
> > To: Paul Durrant
> > Cc: 'Stefano Stabellini' ; qemu-de...@nongnu.org;
> > Anthony Perard ; Wei Liu
> > ; jgr...@suse.com; julien.g
From: Jennifer Herbert
No functional change.
Signed-off-by: Jennifer Herbert
Signed-off-by: Andrew Cooper
--
CC: Paul Durrant
CC: Andrew Cooper
CC: Jan Beulich
CC: Julien Grall
---
xen/arch/x86/hvm/dm.c | 47 ---
1 file changed, 28 insertions(+)
From: Jennifer Herbert
copy_{to,from}_guest_buf() are now implemented using an offset of 0.
Signed-off-by: Andrew Cooper
Signed-off-by: Jennifer Herbert
--
CC: Paul Durrant
CC: Andrew Cooper
CC: Jan Beulich
CC: Julien Grall
---
xen/arch/x86/hvm/dm.c | 48 +-
From: Jennifer Herbert
This new lib devicemodel call allows multiple extents of pages to be
marked as modified in a single call. This is something needed for a
usecase I'm working on.
The xen side of the modified_memory call has been modified to accept
an array of extents. The devicemodel libr
From: Jennifer Herbert
This also allows the usual cases to be simplified, by omitting an unnecessary
buf parameters, and because the macros can appropriately size the object.
This makes copying to or from a buf that isn't big enough an error.
If the buffer isnt big enough, trying to carry on reg
In order to address the concerns raised in XSA-163, I am writing XTF based
tests to validate PMU MSR read/writes from HVM guests.
While testing, I found a scenario where setting the Pin Control Flag bit (19)
of IA32_PERF_EVTSELx results in a General Protection Fault followed by a
hypervisor cras
This patch changes wrmsrl() calls to write to MSR_P6_EVTSEL register in the
VPMU to wrmsr_safe(). There are known (and possibly some unknown) cases where
setting certain bits in MSR_P6_EVTSEL reg. can cause a General Protection
fault on some machines. Unless we catch this fault when it happens, it
On 21/04/17 01:57, Ian Jackson wrote:
> (Resending with the correct CC (!))
>
> We are in discussions with MITRE with a view to potentially becoming a
> CVE Numbering Authority. This would probably smooth the process of
> getting CVE numbers for XSAs.
>
> If anyone has any opinions/representatio
e820 map is updated with information from the zeropage (i.e.
pvh_bootparams) by default_machine_specific_memory_setup().
With the way things are done now, we end up with a duplicated
e820 map.
Signed-off-by: Boris Ostrovsky
---
This patch is against for-linus-4.12 branch. Since this is not
a crit
I committed this series, thank you.
On Thu, 20 Apr 2017, Julien Grall wrote:
> Hi,
>
> Whilst doing some testing on Juno using GRUB, I noticed random early crash
> depending ([1]) on the binaries I was using.
>
> This is because Xen is assuming that the FDT will always fit in a 2MB
> superpage w
On 04/20/2017 12:15 PM, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
>>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>>> it, you propose to somehow deal with its obviously crack induced
>>> behaviour :-(
>> Totally agree and I d
On 20/04/17 16:06, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead
> On 20 Apr 2017, at 14:21, Jan Beulich wrote:
>
On 20.04.17 at 15:02, wrote:
>>> On 20 Apr 2017, at 10:43, Jan Beulich wrote:
>>>
>> On 20.04.17 at 04:14, wrote:
On 17-04-19 03:00:29, Jan Beulich wrote:
On 19.04.17 at 10:22, wrote:
>> On 17-04-18 05:46:43, Jan Be
On Thu, Apr 20, 2017 at 5:26 PM, Jan Beulich wrote:
> Jann's explanation of the problem:
>
> "start situation:
> - domain A and domain B are PV domains
> - domain A and B both have currently scheduled vCPUs, and the vCPUs
>are not scheduled away
> - domain A has XSM_TARGET access to domain
Hi all,
Below the meeting minutes for the previous Xen community call. Feel free to
reply if I missed some parts.
I suggest to have the next call on the 3rd May at 5PM BST. Any opinions.
Also, do you have any specific topic you would like to talk during this
call?
Cheers,
== Attendees ==
S
>>> On 20.04.17 at 18:04, wrote:
> On Thu, Apr 20, Andrew Cooper wrote:
>
>> As it currently stands, the sending side iterates from 0 to p2m_size,
>> and sends every frame on the first pass. This means we get PAGE_DATA
>> records linearly, in batches of 1024, or two aligned 2M superpages.
>
> I
On Thu, Apr 20, 2017 at 04:39:06PM +0100, Julien Grall wrote:
>Hi,
>
>On 20/04/17 14:34, Jan Beulich wrote:
>> > > > On 19.04.17 at 22:22, wrote:
>> > According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> > "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
flight 107556 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107556/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107536
test-armhf-armhf-libvirt-raw 12
Boris Ostrovsky writes:
> On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
>> Peter Zijlstra writes:
>>
>>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
In this patch I suggest we set __max_logical_packages based on the
max_physical_pkg_id and total_cpus,
>>> So my
Eric Blake writes:
> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>
>>
>> No objection to Alistair's idea to turn this into an enumeration.
>
> Question - should the enum be more than just 'guest' and 'host'? For
> example, my patch proves that we have a lot of places that handle
> complime
On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
> > This is getting ludicrous. Xen is plain broken, and instead of fixing
> > it, you propose to somehow deal with its obviously crack induced
> > behaviour :-(
>
> Totally agree and I don't like the solution I propose (and that's w
Hi Vijay,
On 28/03/17 16:53, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
Split numa_initmem_init() so that the numa fallback code is moved
as separate function which is generic.
Signed-off-by: Vijaya Kumar K
---
xen/arch/x86/numa.c | 29 +
1 file changed,
Eric Blake writes:
> On 04/20/2017 07:09 AM, Daniel P. Berrange wrote:
>
+++ b/qapi/event.json
@@ -10,6 +10,10 @@
# Emitted when the virtual machine has shut down, indicating that qemu is
# about to exit.
#
+# @guest: If true, the shutdown was triggered by a guest
This run is configured for baseline tests only.
flight 71209 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71209/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-midway 15 guest-start/debia
On Thu, Apr 20, Andrew Cooper wrote:
> As it currently stands, the sending side iterates from 0 to p2m_size,
> and sends every frame on the first pass. This means we get PAGE_DATA
> records linearly, in batches of 1024, or two aligned 2M superpages.
Is there a way to preserve 1G pages? This 380G
On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
> Peter Zijlstra writes:
>
>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>>> In this patch I suggest we set __max_logical_packages based on the
>>> max_physical_pkg_id and total_cpus,
>> So my 4 socket 144 CPU system will then
Hi Vijay,
On 28/03/17 16:53, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
Add accessor functions for acpi_numa and numa_off static
variables. Init value of acpi_numa is set 1 instead of 0.
Please explain why you change the acpi_numa value from 0 to 1.
Also, I am not sure to understand
(Resending with the correct CC (!))
We are in discussions with MITRE with a view to potentially becoming a
CVE Numbering Authority. This would probably smooth the process of
getting CVE numbers for XSAs.
If anyone has any opinions/representations/concerns/whatever about
this, please do share the
On 20/04/17 16:35, Olaf Hering wrote:
> Andrew,
>
> with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
> xc_domain_populate_physmap_exact was added to the new restore code.
> This call always sets order=0. The old migration code did consider
> superpages, the new one does not.
>
Hi,
On 20/04/17 14:20, Andrew Cooper wrote:
On 20/04/17 14:18, Ross Lagerwall wrote:
Use the return value from early_microcode_update_cpu rather than
ignoring it.
Spotted by Coverity.
Signed-off-by: Ross Lagerwall
Reviewed-by: Andrew Cooper
Julien, can we have a release ack please?
Hi,
On 20/04/17 15:11, Andrew Cooper wrote:
On 20/04/17 14:48, Jan Beulich wrote:
Match rcu_lock_domain(), and remove the slightly misleading comment:
This isn't just the companion to rcu_lock_domain_by_id() (and that
latter function indeed also keeps the domain locked, not the domain
list).
N
Peter Zijlstra writes:
> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
>
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead of 4.
>
> This
Hi,
On 20/04/17 14:34, Jan Beulich wrote:
On 19.04.17 at 22:22, wrote:
According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
and APIC ID are preserved when handling INIT signal and a reset places
APIC to xA
We are in discussions with MITRE with a view to potentially becoming a
CVE Numbering Authority. This would probably smooth the process of
getting CVE numbers for XSAs.
If anyone has any opinions/representations/concerns/whatever about
this, please do share them (here in this thread, or privately
Andrew,
with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
xc_domain_populate_physmap_exact was added to the new restore code.
This call always sets order=0. The old migration code did consider
superpages, the new one does not.
What is the reason for not using superpages when
Jann's explanation of the problem:
"start situation:
- domain A and domain B are PV domains
- domain A and B both have currently scheduled vCPUs, and the vCPUs
are not scheduled away
- domain A has XSM_TARGET access to domain B
- page X is owned by domain B and has no mappings
- page X is
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses to the
PCI configuration space and react accordingly.
Patch 1 implements the generic handlers for accesses to the PCI configuration
space together wi
Add handlers for accesses to the MSI-X message control field on the PCI
configuration space, and traps for accesses to the memory region that contains
the MSI-X table. This traps detect attempts from the guest to configure MSI-X
interrupts and properly sets them up.
Note that accesses to the Table
Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them on
request.
All capabilities from the device are fetched and stored in an internal list,
that's later used in order to return the next capability to the guest. Note
that this only removes the capability from the linked list
Add handlers for the MSI control, address, data and mask fields in order to
detect accesses to them and setup the interrupts as requested by the guest.
Note that the pending register is not trapped, and the guest can freely
read/write to it.
Whether Xen is going to provide this functionality to D
This functionality is going to reside in vpci.c (and the corresponding vpci.h
header), and should be arch-agnostic. The handlers introduced in this patch
setup the basic functionality required in order to trap accesses to the PCI
config space, and allow decoding the address and finding the correspo
And also allow it to do non-identity mappings by adding a new parameter. This
function will be needed in other parts apart from PVH Dom0 build.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 22 +-
xen/common/memory.
Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to emulate BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to memory
space accesses), and maps/unmaps the BARs of the device into the guest p2m.
The BA
And mark the capability and header vPCI register initializers as high priority,
so that they are initialized first.
This is needed for MSI-X, since MSI-X needs to know the position of the BARs in
order to perform it's initialization, and in order to mask or enable the
MSI/MSI-X functionality on de
Introduce a set of handlers for the accesses to the ECAM areas. Those areas are
setup based on the contents of the hardware MMCFG tables, and the list of
handled ECAM areas is stored inside of the hvm_domain struct.
The read/writes are forwarded to the generic vpci handlers once the address is
dec
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/pci.c | 86 ++
There is currently no sanity check on the FDT passed by the bootloader.
Whilst they are stricly not necessary, it will avoid us to spend hours
to try to find out why it does not work.
From the booting documentation for AArch32 [1] and AArch64 [2] must :
- be placed on 8-byte boundary
- not
Currently, Xen is assuming the FDT will always fit in a 2MB section.
Recently, I noticed an early crash on Xen when using GRUB with the
following call trace:
(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable arm64
This function will be called by other function later one. This will
avoid forward declaration and keep the new function close to sibling
ones.
This was moved just after *_fixmap helpers as they are page table
handling functions too.
Signed-off-by: Julien Grall
---
Changes in v2:
- P
The FDT will not be accessed before start_xen (begining of C code) is
called and it will be easier to maintain as the code could be common
between AArch32 and AArch64.
A new function early_fdt_map is introduced to map the FDT in the boot
page table.
Signed-off-by: Julien Grall
Reviewed-by: Stefa
Hi,
Whilst doing some testing on Juno using GRUB, I noticed random early crash
depending ([1]) on the binaries I was using.
This is because Xen is assuming that the FDT will always fit in a 2MB
superpage whilst the boot documentation allow the FDT to cross a 2MB boundary.
The first patch move th
The 2 new defines will help to avoid hardcoding the size and the end of
the slot in the code.
The newlines are added for clarity.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/include/asm-arm/config.h | 4
1
On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
> In this patch I suggest we set __max_logical_packages based on the
> max_physical_pkg_id and total_cpus,
So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
instead of 4.
This wastes quite a bit of memory for the
>>> On 20.04.17 at 09:37, wrote:
> On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
> On 20.04.17 at 08:59, wrote:
>>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>> On 19.04.17 at 22:22, wrote:
> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROL
flight 107563 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107563/
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-armhf-armhf-xl 12 mig
>>> On 20.04.17 at 16:11, wrote:
> On 20/04/17 14:48, Jan Beulich wrote:
>> Match rcu_lock_domain(), and remove the slightly misleading comment:
>> This isn't just the companion to rcu_lock_domain_by_id() (and that
>> latter function indeed also keeps the domain locked, not the domain
>> list).
>>
On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
On 20.04.17 at 08:59, wrote:
>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>> On 19.04.17 at 22:22, wrote:
According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"EXTENDED XAPIC (X2AP
Hi Stefano,
On 19/04/17 22:56, Stefano Stabellini wrote:
On Wed, 19 Apr 2017, Julien Grall wrote:
On 19/04/2017 22:01, Stefano Stabellini wrote:
On Wed, 19 Apr 2017, Julien Grall wrote:
@@ -113,12 +113,12 @@
#define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
#define
>>> On 20.04.17 at 08:59, wrote:
> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
> On 19.04.17 at 22:22, wrote:
>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>> and APIC ID
On 20/04/17 14:48, Jan Beulich wrote:
> Match rcu_lock_domain(), and remove the slightly misleading comment:
> This isn't just the companion to rcu_lock_domain_by_id() (and that
> latter function indeed also keeps the domain locked, not the domain
> list).
>
> No functional change, as rcu_read_{,un
On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
On 19.04.17 at 22:22, wrote:
>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> and APIC ID are preserved when handling INIT signal
Match rcu_lock_domain(), and remove the slightly misleading comment:
This isn't just the companion to rcu_lock_domain_by_id() (and that
latter function indeed also keeps the domain locked, not the domain
list).
No functional change, as rcu_read_{,un}lock() ignore their arguments
anyway.
Reported-
>>> On 19.04.17 at 22:22, wrote:
> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
> and APIC ID are preserved when handling INIT signal and a reset places
> APIC to xAPIC mode and APIC base address to
On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>
> No objection to Alistair's idea to turn this into an enumeration.
Question - should the enum be more than just 'guest' and 'host'? For
example, my patch proves that we have a lot of places that handle
complimentary machine commands to reset a
Recent changes in logical package management (Commit 9d85eb9119f4
("x86/smpboot: Make logical package management more robust") and its
predecessor) caused boot failures for some Xen guests. E.g. I'm trying to
boot 10 CPU guest on AMD Opteron 4284 system and I see the following crash:
[0.116104
On 20/04/17 14:18, Ross Lagerwall wrote:
> Use the return value from early_microcode_update_cpu rather than
> ignoring it.
Spotted by Coverity.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by: Andrew Cooper
Julien, can we have a release ack please?
~Andrew
>>> On 20.04.17 at 15:02, wrote:
>> On 20 Apr 2017, at 10:43, Jan Beulich wrote:
>>
> On 20.04.17 at 04:14, wrote:
>>> On 17-04-19 03:00:29, Jan Beulich wrote:
>>> On 19.04.17 at 10:22, wrote:
> On 17-04-18 05:46:43, Jan Beulich wrote:
> On 18.04.17 at 12:55, wrote:
>>
On 04/20/2017 07:09 AM, Daniel P. Berrange wrote:
>>> +++ b/qapi/event.json
>>> @@ -10,6 +10,10 @@
>>> # Emitted when the virtual machine has shut down, indicating that qemu is
>>> # about to exit.
>>> #
>>> +# @guest: If true, the shutdown was triggered by a guest request (such as
>>> +# execu
Use the return value from early_microcode_update_cpu rather than
ignoring it.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/microcode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 4e7dfcd..7558202 100644
--- a/xen
On 20/04/17 13:18, osstest service owner wrote:
> flight 107553 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/107553/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-xsm 5 xen-
The use of $info->{FirstTip}{flight} autovivifies $info->{FirstTip}.
Defend $pinfo against the use of an autovivified empty hashref.
Signed-off-by: Ian Jackson
---
sg-report-flight |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sg-report-flight b/sg-report-flight
index 7d
In bd648aea2ebe
sg-report-flight: report allowable regressions separately in summary
whether the regression was allowable was put in $allow, but this
was erroneously not used.
In 4a210cda9cc8
sg-report-flight: fix allowable failure logic not to reuse $allow for two
purposes (!)
that use of the
Apologies for stepping in here. But it feels to me that this thread is at risk
of becoming unproductive.
> On 20 Apr 2017, at 10:43, Jan Beulich wrote:
>
On 20.04.17 at 04:14, wrote:
>> On 17-04-19 03:00:29, Jan Beulich wrote:
>> On 19.04.17 at 10:22, wrote:
On 17-04-18 05:46:43
Hi Stefano,
On 19/04/17 22:18, Stefano Stabellini wrote:
On Wed, 19 Apr 2017, Julien Grall wrote:
On 19/04/2017 22:01, Stefano Stabellini wrote:
On Wed, 19 Apr 2017, Julien Grall wrote:
I would have added early_fdt_map to this file in a way to avoid the need
for duplicating the declaration of
1 - 100 of 135 matches
Mail list logo