On Mon, Dec 05, 2016 at 01:32:43PM -0800, Andy Lutomirski wrote:
> Aside from being excessively slow, CPUID is problematic: Linux runs
> on a handful of CPUs that don't have CPUID. Use IRET-to-self
> instead. IRET-to-self works everywhere, so it makes testing easy.
>
> For reference, On my lapto
On 05/12/16 18:17, Jan Beulich wrote:
On 05.12.16 at 17:34, wrote:
>> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
>> caller's buffer can't hold all entries.
>>
>> This is a problem as the caller has normally a static buffer defined
>> and when he is doing the call no dy
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Wei Liu wrote:
> > Dear community members,
> >
> > I'm pleased to announce that Julien Grall will be
> > the Release Manager for the next Xen release.
> >
> > The appointment was voted by the Committers and
Commit d4016288ab1f ("xenstore: support XS_DIRECTORY_PART in
libxenstore") introduced a theoretical bug: the generation count of
the read node is transferred via strncpy without forcing a NUL byte
at the end. Correct this.
Signed-off-by: Juergen Gross
---
tools/xenstore/xs.c | 4 ++--
1 file cha
On 05/12/16 19:19, Andrew Cooper wrote:
> On 05/12/16 12:05, Wei Liu wrote:
>> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
>> [...]
>>> Juergen Gross (12):
>>> xenstore: modify add_change_node() parameter types
>>> xenstore: call add_change_node() directly when writing node
>
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 102940 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102940/
Failures :-/
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, December 05, 2016 6:09 PM
>
> The current hvm_msr_{read,write}_intercept() infrastructure calls
> hvm_inject_hw_exception() directly to latch a fault, and returns
> X86EMUL_EXCEPTION to its caller.
>
> This behaviour is prob
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 06, 2016 2:25 AM
>
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
> infrastructure.
>
> Signed-off-by:
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 06, 2016 2:25 AM
>
> This reduces the net complexity of CPUID handling by having all adjustments in
remove 'in'
> at the same place. Remove the now-unused hvm_funcs.cpuid_intercept
> infrastructure.
>
> The SYSC
On 05/12/16 21:53, Dan Carpenter wrote:
> On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote:
>> On 19/11/16 19:22, Quentin Lambert wrote:
>>> Most error branches following the call to kmalloc contain
>>> a call to kfree. This patch add these calls where they are
>>> missing.
>>>
>>> Thi
Hi Andrew,
On Sun, Dec 04, 2016 at 03:59:20PM +, Andrew Cooper wrote:
> On 04/12/16 08:32, Andy Smith wrote:
> > Under the Debian jessie amd64 kernel (linux-image-3.16.0-4-amd64
> > 3.16.36-1+deb8u2) running under Xen, I cannot put the system's
> > storage under heavy load without receiving a
flight 102929 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102929/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl-vhd b
Changes in v2:
- fix copy/paste error
- rename ring-ref- to ring-ref
- fix memory barriers
- add "verify prod/cons against local copy"
- add a paragraph on high level design
- add a note on the maximum possible max-ring-page-order value
- add mechanisms to avoid unnecessary evtchn notifications
--
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 102941 qemu-upstream-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102941/
Fai
On 05/12/2016 19:17, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Andrew Cooper wrote:
>> None of these barriers serve any purpose, as they are not synchronising with
>> any anything on remote CPUs.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Stefano Stabellini
>> CC:
On 05/12/2016 20:41, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
>> On Mon, 5 Dec 2016, Wei Liu wrote:
>>> Dear community members,
>>>
>>> I'm pleased to announce that Julien Grall will be
>>> the Release Manager for the next Xen release.
>>>
flight 102920 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102920/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101675
test-amd64-amd
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index fa808ef..5d0830e 100644
--- a/xen/arch/x86/setup.c
+++ b
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without p
..nor EFI platforms with runtime services enabled.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
v6 - suggestions/fixes:
- move this commit behind "efi: create efi_enabled()" commit
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- fix build err
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
---
v9 - suggestions/fixes:
- use
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v10 - suggestions/fixes:
- replace ljmpl with lretq
(suggested by Andrew Cooper),
- introduce efi_platform to increase code readability
First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and
This patch is prereq for "efi: build xen.gz with EFI code" patch which adds,
among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there
is a description why it is needed.
Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. Howev
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
Hi,
I am sending eleventh version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
flight 102967 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102967/
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
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 2 +-
1 file c
*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL ***
Alan Cox pointed out that the 486 isn't the only supported CPU that
doesn't have CPUID. Let's clean up the mess and make everything
faster while we're at it.
Patch 1 is intended to be an easy fix: it makes sync_core() work
without CPUID on all 32-bit k
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1". I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.
Reported-by: Henrique de Moraes Holschuh
Acked-by: Borislav Petkov
Signed-off-by: Andy Lutomirski
-
Aside from being excessively slow, CPUID is problematic: Linux runs
on a handful of CPUs that don't have CPUID. Use IRET-to-self
instead. IRET-to-self works everywhere, so it makes testing easy.
For reference, On my laptop, IRET-to-self is ~110ns,
CPUID(eax=1, ecx=0) is ~83ns on native and very
This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98.
The patch wasn't quite correct -- there are non-Intel (and hence
non-486) CPUs that we support that don't have CPUID. Since we no
longer require CPUID for sync_core(), just revert the patch.
I think the relevant CPUs are Geode and Ela
On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place. Remove the now-unused hvm_funcs.cpuid_intercept
> infrastructure.
>
> The SYSCALL feature hiding is tweaked when moved. In principle, an
> administrat
On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> core2_no_vpmu_ops exists solely to work around the default-leaking of
> CPUID/MSR
> values in Xen.
>
> With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
> remaining hook. Since core2_no_vpmu_ops's introduction in c/s 2525
On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
> *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
> }
> +
> +
On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote:
> On 19/11/16 19:22, Quentin Lambert wrote:
> > Most error branches following the call to kmalloc contain
> > a call to kfree. This patch add these calls where they are
> > missing.
> >
> > This issue was found with Hector.
> >
> > Si
* Hardware:
Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
Sandisk SSD 1T
32G Ram
Linux xen 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux
* Software:
Debian Stretch/testing is dom0
* Guest operating systems:
Guests Ubuntu 14.04 LTS Debian Stretch/Sid
Ubuntu 16.10 yakity
On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Wei Liu wrote:
> > Dear community members,
> >
> > I'm pleased to announce that Julien Grall will be
> > the Release Manager for the next Xen release.
> >
> > The appointment was voted by the Committers and
On Mon, 5 Dec 2016, Wei Liu wrote:
> Dear community members,
>
> I'm pleased to announce that Julien Grall will be
> the Release Manager for the next Xen release.
>
> The appointment was voted by the Committers and the vote passed.
>
> Julien has done excellent jobs in many aspects. He has been
On Mon, 5 Dec 2016, Julien Grall wrote:
> Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible
> to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register
> (ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface.
>
> When the guest has been configured
On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 01/12/16 21:33, Stefano Stabellini wrote:
> > On Thu, 1 Dec 2016, Julien Grall wrote:
> > > On 01/12/16 02:07, Stefano Stabellini wrote:
> > > > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > > > Hi Stefano,
> > >
> > > Hi,
> > >
> > >
This run is configured for baseline tests only.
flight 68162 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68162/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
baseline v
On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 03/12/16 00:46, Stefano Stabellini wrote:
> > On Fri, 2 Dec 2016, Andre Przywara wrote:
> > > > When we receive the maintenance interrupt and we clear the LR of the
> > > > vLPI, Xen should re-enable the pLPI.
> > > > Given that the stat
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch adds APIC ID in the struct ioapic_sbdf,
which is used to match the entry when searchi
flight 102959 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102959/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 broken
test-a
On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 15:17, wrote:
> > From a security purist point of view, any delay in publication could
> > increase the possibility of vulnerabilities being exploited in the
> > wild. However, given the significant frequency of publication of XSAs,
> >
On 12/5/16 10:45 AM, Wei Liu wrote:
> The file provided contains symbols that must be set to certain values.
> This then prevents random build breakage in travis due to
> known-incompatible symbol selections.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Doug Goldstein
> ---
> scripts/travis-build | 2
On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 14:59, wrote:
> > On 05/12/16 13:50, Jan Beulich wrote:
> > On 05.12.16 at 14:43, wrote:
> >>> On 05/12/16 12:28, Jan Beulich wrote:
> >>> On 05.12.16 at 12:25, wrote:
> > On 05/12/16 11:18, Jan Beulich wrote:
> > On
On Mon, 5 Dec 2016, Andrew Cooper wrote:
> None of these barriers serve any purpose, as they are not synchronising with
> any anything on remote CPUs.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
>
> Restricting to just the $ARCH maintai
On Mon, 5 Dec 2016, Andrew Cooper wrote:
> Mandatory barriers are only for use with reduced-cacheability MMIO mappings.
>
> All of these uses are just to deal with shared memory between multiple
> processors, so use the smp_*() which are the correct barriers for the purpose.
>
> Signed-off-by: An
On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Oleksandr,
>
> On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
> > Call irq_get_domain for the IRQ we are interested in
> > only after making sure that it is the guest IRQ to avoid
> > ASSERT(test_bit(_IRQ_GUEST, &desc->status)) triggering.
> >
> > Sign
flight 102914 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102914/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs. 10
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
This involves introducing a vpmu_enabled() predicate, and making the Intel
specific VPMU_CPU_HAS_* constants public.
Signed-off-by: Andrew Coope
core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR
values in Xen.
With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
intel: Add cpuid handling when vpmu disabled",
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused hvm_funcs.cpuid_intercept
infrastructure.
The SYSCALL feature hiding is tweaked when moved. In principle, an
administrator can choose to explicitly hide the SYSCALL feature fro
This is some cleanup intended to ease the development of further development
work. There is no practical change from a guests point of view.
Andrew Cooper (4):
x86/vpmu: Move vpmu_do_cpuid() handling into {pv,hvm}_cpuid()
x86/vpmu: Remove core2_no_vpmu_ops
x86/hvm: Move hvm_funcs.cpuid_inte
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
infrastructure.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
v2:
* Reorder the position of the blanke
On 05/12/16 12:05, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
> [...]
>> Juergen Gross (12):
>> xenstore: modify add_change_node() parameter types
>> xenstore: call add_change_node() directly when writing node
>> xenstore: use common tdb record header in x
flight 102921 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102921/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 102830
Regress
On 12/5/16 10:45 AM, Wei Liu wrote:
> This would be used to force selection of certain items in randconfig.
>
> We need this to force gcov format to be autodetected in randconfig
> target, which would avoid generating known-incompatible combinations.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Doug G
It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
E820_X_MAX is always at least slightly larger than E820MAX.
The real motivation behind this is actually to prevent some issues in
the Xen kernel, where the XE
This is the third pass at my patchset to fix up our problems with
XENMEM_machine_memory_map on large systems. The only changes on this
pass were to flesh out the comment above the E820_X_MAX definition, and
to add Juergen's Reviewed-by to the second patch.
Let me know if anyone has any questions/
On systems with sufficiently large e820 tables, and several IOAPICs, it
is possible for the XENMEM_machine_memory_map callback (and its
counterpart, XENMEM_memory_map) to attempt to return an e820 table with
more than 128 entries. This callback adds entries to the BIOS-provided
e820 table to accou
flight 102948 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102948/
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
Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible
to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register
(ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface.
When the guest has been configured to use GICv2, the hypervisor will
disable sysreg a
>>> On 05.12.16 at 17:34, wrote:
> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
> caller's buffer can't hold all entries.
>
> This is a problem as the caller has normally a static buffer defined
> and when he is doing the call no dynamic memory allocation is
> possible as no
>>> On 05.12.16 at 17:29, wrote:
> On 05/12/16 12:10, Jan Beulich wrote:
> On 05.12.16 at 11:09, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v)
>>>
>>> if ( w->do_write.msr )
>>> {
>>> -
On 05/12/16 16:43, Juergen Gross wrote:
> On 05/12/16 17:39, Andrew Cooper wrote:
>> On 05/12/16 16:34, Juergen Gross wrote:
>>> Today's interface to get the machine memory map in dom0 requires to
>>> know in advance how large the final map will be. There is however no
>>> way to either get only a
On 05/12/16 16:45, Wei Liu wrote:
> The file provided contains symbols that must be set to certain values.
> This then prevents random build breakage in travis due to
> known-incompatible symbol selections.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
__
On 05/12/16 16:45, Wei Liu wrote:
> This would be used to force selection of certain items in randconfig.
>
> We need this to force gcov format to be autodetected in randconfig
> target, which would avoid generating known-incompatible combinations.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Doug Golds
flight 102915 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102915/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
baseline version:
ovmf 7bbe0b3eff9e7876808ce
Wei Liu (2):
Kconfig: introduce allrandom.config
Travis-ci: specify KCONFIG_ALLCONFIG for randconfig
scripts/travis-build | 2 +-
xen/tools/kconfig/allrandom.config | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 xen/tools/kconfig/allrandom.config
--
This would be used to force selection of certain items in randconfig.
We need this to force gcov format to be autodetected in randconfig
target, which would avoid generating known-incompatible combinations.
Signed-off-by: Wei Liu
---
Cc: Doug Goldstein
---
xen/tools/kconfig/allrandom.config |
The file provided contains symbols that must be set to certain values.
This then prevents random build breakage in travis due to
known-incompatible symbol selections.
Signed-off-by: Wei Liu
---
Cc: Doug Goldstein
---
scripts/travis-build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On 05/12/16 17:39, Andrew Cooper wrote:
> On 05/12/16 16:34, Juergen Gross wrote:
>> Today's interface to get the machine memory map in dom0 requires to
>> know in advance how large the final map will be. There is however no
>> way to either get only a part of the memory map or to ask the
>> hyperv
On 05/12/16 16:34, Juergen Gross wrote:
> Today's interface to get the machine memory map in dom0 requires to
> know in advance how large the final map will be. There is however no
> way to either get only a part of the memory map or to ask the
> hypervisor about its size.
>
> This patch set enhanc
On 08/11/16 07:29, Juergen Gross wrote:
> The dependency for setting up the links for ioemu is wrong: it is
> depending on tools/qemu-xen-traditional-dir which is being modified by
> each "make tools" call. This leads to rebuilds of several stubdom
> libraries for each call of "make stubdom" as tho
Today there is no way for a domain to obtain the number of entries of
the machine memory map returned by XENMEM_machine_memory_map hypercall.
Modify the interface to return just the needed number of map entries
in case the buffer was specified as NULL.
Signed-off-by: Juergen Gross
---
xen/arch/
Today's interface to get the machine memory map in dom0 requires to
know in advance how large the final map will be. There is however no
way to either get only a part of the memory map or to ask the
hypervisor about its size.
This patch set enhances the XENMEM_machine_memory_map hypercall to
solve
For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
caller's buffer can't hold all entries.
This is a problem as the caller has normally a static buffer defined
and when he is doing the call no dynamic memory allocation is
possible as nothing is yet known about the system's memory l
On 05/12/16 12:10, Jan Beulich wrote:
On 05.12.16 at 11:09, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v)
>>
>> if ( w->do_write.msr )
>> {
>> -hvm_msr_write_intercept(w->msr, w
flight 102905 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 52 leak-check/check fail REGR. vs. 102721
test-xtf-amd64-
On Mon, Dec 05, 2016 at 08:58:20AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 16:27, wrote:
> > On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
> >> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> >> > >>> On 05.12.16 at 15:39, wrote:
> >> > > Introduce CONFIG_LTO in K
>>> On 05.12.16 at 16:27, wrote:
> On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
>> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
>> > >>> On 05.12.16 at 15:39, wrote:
>> > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
>> > > converted to Kconfig
On 05/12/16 16:32, Boris Ostrovsky wrote:
> On 12/02/2016 01:15 AM, Juergen Gross wrote:
>>
>> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info
>> *info)
>> +static int scsifront_do_request(struct vscsifrnt_info *info,
>> +struct vscsifrnt_shado
On Mon, Dec 05, 2016 at 03:04:53PM +, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> ---
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 12/02/2016 01:15 AM, Juergen Gross wrote:
>
> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
> +static int scsifront_do_request(struct vscsifrnt_info *info,
> + struct vscsifrnt_shadow *shadow)
> {
> struct vscsiif_front_ring *
On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> > >>> On 05.12.16 at 15:39, wrote:
> > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> > > converted to Kconfig, delete the preceding comment in Rules.
On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 15:39, wrote:
> > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> > converted to Kconfig, delete the preceding comment in Rules.mk as well.
> >
> > Make it depend on BROKEN because it doesn't
There's no such controler available for PVHv2 guests.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
tools/firmware/hvmloader/util.c | 2 +-
tools/libac
PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
Changes since v2:
- Fix usage of ACPI_8042 in the static boot tables.
---
tools/libacpi/acpi2_0.h | 4 ++--
tools/libacpi/stati
On 05/12/16 15:04, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Update the structure of the FADT table to version 5, and use that version for
PVHv2 guests. Note that HVM guests will continue to use FADT 4.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.
1 - 100 of 195 matches
Mail list logo
