flight 107546 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107546/
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
Tests which are faili
On 4/19/2017 10:09 PM, Andrew Cooper wrote:
On 19/04/17 15:07, Jan Beulich wrote:
On 19.04.17 at 15:58, wrote:
On 19/04/17 14:50, Yu Zhang wrote:
On 4/19/2017 9:34 PM, Jan Beulich wrote:
On 19.04.17 at 13:44, wrote:
On 4/19/2017 7:19 PM, Jan Beulich wrote:
On 19.04.17 at 11:48, wrote:
flight 107548 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107548/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail in 107534 pass in 107548
te
> -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.gr...@arm.com; xen-
> de...@lists.xenproject.org
> Subje
flight 71208 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71208/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64-pvops 2 hosts-allocate broken never pass
build-arm64
>>> On 19.04.17 at 19:16, wrote:
> On Wed, Apr 19, 2017 at 10:19:44AM -0600, Jan Beulich wrote:
>> >>> On 19.04.17 at 17:54, wrote:
>> > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote:
>> >> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
>> >> if ( ret
>>> 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 09:15, wrote:
> And back to the schedule of this feature, are you working on it? Or any
> specific plan?
Well, the HVM side is basically ready (as said, the single hunk needed
to support UMIP when hardware supports it could be easily split off of
my emulation patch). For the P
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it? Or any
specific plan?
Well, the HVM side is basically ready (as said, the single hunk needed
to support UMIP when hardware supports it could be easily split
>>> On 19.04.17 at 21:33, wrote:
> On Wed, Apr 19, 2017 at 03:41:41PM +0800, Chao Gao wrote:
-vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
-APIC_DEFAULT_PHYS_BASE);
+vlapic->hw.apic_base_msr |= APIC_DEFAULT_PHYS_BASE;
>>>
>>>Perhaps
On Thu, Apr 20, 2017 at 03:38:50PM +1000, NeilBrown wrote:
> bios that are re-submitted will pass through blk_queue_split() when
> blk_queue_bio() is called, and this will split the bio if necessary.
> There is no longer any need to do this splitting in xen-blkfront.
>
> Signed-off-by: NeilBrown
>>> On 20.04.17 at 11:53, wrote:
> On 4/20/2017 5:47 PM, Jan Beulich wrote:
> On 20.04.17 at 09:15, wrote:
>>> And back to the schedule of this feature, are you working on it? Or any
>>> specific plan?
>> Well, the HVM side is basically ready (as said, the single hunk needed
>> to support UMI
On 4/20/2017 6:01 PM, Jan Beulich wrote:
On 20.04.17 at 11:53, wrote:
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it? Or any
specific plan?
Well, the HVM side is basically ready (as said, the single hun
Christian Lindig writes ("Re: [PATCH for-4.9 v2 0/3] oxenstored: make it work
on FreeBSD"):
> This approach adds two new entries into oxenstored.conf that are
> determined by the configure script. I prefer it over the previous
> design not the least because it results in a much smaller change and
On 20/04/17 11:10, Yu Zhang wrote:
>
>
> On 4/20/2017 6:01 PM, Jan Beulich wrote:
> On 20.04.17 at 11:53, wrote:
>>> On 4/20/2017 5:47 PM, Jan Beulich wrote:
>>> On 20.04.17 at 09:15, wrote:
> And back to the schedule of this feature, are you working on it?
> Or any
> specific
On Tue, Apr 18, 2017 at 04:31:42PM +0100, Wei Liu wrote:
> The default values are Linux device names. No users yet.
>
> Signed-off-by: Wei Liu
Since it's FreeBSD related stuff:
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xe
On Tue, Apr 18, 2017 at 04:31:44PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 4/20/2017 6:23 PM, Andrew Cooper wrote:
On 20/04/17 11:10, Yu Zhang wrote:
On 4/20/2017 6:01 PM, Jan Beulich wrote:
On 20.04.17 at 11:53, wrote:
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it?
Or a
On Thu, Apr 20, 2017 at 03:34:21AM -0600, Jan Beulich wrote:
> >>> On 19.04.17 at 19:16, wrote:
> > On Wed, Apr 19, 2017 at 10:19:44AM -0600, Jan Beulich wrote:
> >> >>> On 19.04.17 at 17:54, wrote:
> >> > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote:
> >> >> @@ -1193,6 +1194,9 @
>>> On 19.04.17 at 23:01, wrote:
> The spinlock in kexec_swap_images() was removed as
> this function is only reachable on the kexec hypercall, which is
> now protected at the top-level in do_kexec_op_internal(),
> thus the local spinlock is no longer necessary.
>
> Per recommendation from Jan Be
>>> On 19.04.17 at 17:58, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2833,10 +2833,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>
> default:
> unexpected_exit_type:
> -gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#
>>> On 20.04.17 at 12:42, wrote:
> On Thu, Apr 20, 2017 at 03:34:21AM -0600, Jan Beulich wrote:
>> >>> On 19.04.17 at 19:16, wrote:
>> > On Wed, Apr 19, 2017 at 10:19:44AM -0600, Jan Beulich wrote:
>> >> >>> On 19.04.17 at 17:54, wrote:
>> >> > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVo
flight 107552 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107552/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 107537 pass
in 107552
test-armhf-armhf-xl-rt
On 20/04/17 11:52, Jan Beulich wrote:
> >>> On 19.04.17 at 17:58, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2833,10 +2833,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>
>> default:
>> unexpected_exit_type:
>> -gdprintk(X
>>> On 20.04.17 at 13:01, wrote:
> On 20/04/17 11:52, Jan Beulich wrote:
>> >>> On 19.04.17 at 17:58, wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -2833,10 +2833,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>>
>>> default:
>>> u
Eric Blake writes:
> 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 host
> signal (but NOT b
On Thu, Apr 20, 2017 at 01:59:29PM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > 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
> > alre
On 20/04/17 11:46, Jan Beulich wrote:
On 19.04.17 at 23:01, wrote:
>> The spinlock in kexec_swap_images() was removed as
>> this function is only reachable on the kexec hypercall, which is
>> now protected at the top-level in do_kexec_op_internal(),
>> thus the local spinlock is no longer nec
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-buildfail REGR. vs. 107539
Regressions which
Hi Bhupinder,
On 03/04/17 10:44, Bhupinder Thakur wrote:
tools/console/client/main.c | 6 +
tools/console/daemon/io.c| 532 +++
tools/libxc/include/xc_dom.h | 3 +
tools/libxc/xc_dom_arm.c | 7 +-
tools/libxc/xc_dom_boot.c
flight 107554 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 107545
test-amd64-amd64-xl-qemuu-
Hi,
On 20/04/17 11:22, Ian Jackson wrote:
Christian Lindig writes ("Re: [PATCH for-4.9 v2 0/3] oxenstored: make it work on
FreeBSD"):
This approach adds two new entries into oxenstored.conf that are
determined by the configure script. I prefer it over the previous
design not the least because
On Thu, Apr 20, 2017 at 01:14:30PM +0100, Andrew Cooper wrote:
> On 20/04/17 11:46, Jan Beulich wrote:
> On 19.04.17 at 23:01, wrote:
> >> The spinlock in kexec_swap_images() was removed as
> >> this function is only reachable on the kexec hypercall, which is
> >> now protected at the top-lev
Hi Andrew,
On 20/04/17 13:14, Andrew Cooper wrote:
On 20/04/17 11:46, Jan Beulich wrote:
On 19.04.17 at 23:01, wrote:
The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
t
Hi Andrew,
On 19/04/17 16:58, Andrew Cooper wrote:
* Use gprintk rather than gdprintk. These logging messages shouldn't
disappear in release builds, as they usually happen immediately before a
domain crash. Raise them from WARNING to ERR.
* Format the vmexit reason in the same base as
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
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
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
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-
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 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
>>> 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 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
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 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
>>> 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
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 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
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 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
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 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
>>> 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).
>>
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 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
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
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
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 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
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
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
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
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 ++
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
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 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.
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
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
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
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
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
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
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 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
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?
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.
>
(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
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
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
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
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
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
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,
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
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
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
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
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
>>> 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
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 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
> 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 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 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
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
1 - 100 of 135 matches
Mail list logo
