>>> On 01.09.16 at 23:19, wrote:
> On Thu, Sep 01, 2016 at 01:46:24AM -0600, Jan Beulich wrote:
>> >>> On 31.08.16 at 22:50, wrote:
>> > On Wed, Aug 31, 2016 at 09:46:31AM -0600, Jan Beulich wrote:
>> >> >>> On 31.08.16 at 16:59, wrote:
>> >> > On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beuli
>>> On 02.09.16 at 04:55, wrote:
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -30,6 +30,7 @@
> */
>
> #define HVM_PARAM_CALLBACK_IRQ 0
> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
This covering the top 8 bits, just the shift value might indeed b
On 02/09/16 03:21, Samuel Thibault wrote:
> Hello,
>
> Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
>> I stumbled over the problem with xenstore-stubdom: xenstore is using
>> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
>> build error with Mini-OS (console_evtc
flight 100710 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100710/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b8922094f6f8b5293f01a09035b74463fff12320
baseline version:
ovmf 3ef3209d3028b77af9f56
This run is configured for baseline tests only.
flight 67623 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67623/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ef3209d3028b77af9f56f183370e7b67cd7c849
baseline v
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:49 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 6/6]
Hello.
I'm recently trying to utilize the virtualization exception (#VE) feature.
As the document says, #VE is handled by guest interrupt handler. The IRQ
number of #VE is 20. However, when I tried to register an IRQ handler for
#VE, it returns errno -22, which means invalid arguments.
request_ir
From: Shannon Zhao
Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().
Also use HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT in hvm_set_callback_via().
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Shannon Zhao
---
xen/arch/arm/domain_build.c | 8 +
From: Shannon Zhao
Construct GTDT table with the interrupt information of timers.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 83ad954..93ba2d1 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/
From: Shannon Zhao
Here it adds the ACPI tables size to set the target maxmem to avoid
providing less available memory for guest.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arch.h| 2 +-
tools/libxl/libxl_arm.c | 18 +-
tools/libxl/libxl_arm.h |
From: Shannon Zhao
Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/lib
From: Shannon Zhao
The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.
Then, it copies these ACPI tables to DomU non-RAM memory map space and
passes them to UEFI firmware through the "ARM mul
From: Shannon Zhao
Estimate the size of ACPI tables and reserve a memory map space for ACPI
tables.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 98
1 file changed, 98 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tool
From: Shannon Zhao
It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI. And the generation codes
are only built for 64-bit toolstack.
Signed-off-by: Shannon Zhao
---
tools/libxl/Makefile| 7 +
tools/libxl/libxl
From: Shannon Zhao
The guest kernel will get the event channel interrupt information via
domain param HVM_PARAM_CALLBACK_IRQ. Initialize it here.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b
From: Shannon Zhao
Since the existing configuration option "u.hvm.acpi" is x86 specific and
we want to reuse it on ARM as well, add a unified option "acpi" for
x86 and ARM, and for ARM it's disabled by default.
Signed-off-by: Shannon Zhao
---
docs/man/xl.cfg.pod.5.in | 1 +
tools/libxl/lib
From: Shannon Zhao
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
needs to add -D__XEN_TOOLS__ to co
From: Shannon Zhao
According to the GIC version, construct the MADT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 84
1 file changed, 84 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index d3358b3..407f9d5 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/l
From: Shannon Zhao
Rename finalise_one_memory_node to finalise_one_node and pass the node
name via function parameter.
This is useful for adding ACPI module which will be added by a later
patch.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
---
tools/libxl/libxl_arm.c | 8
1 fi
From: Shannon Zhao
Copy the static DSDT table into ACPI blob.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 407f9d5..30e4d66 100644
--- a/tools/libxl
From: Shannon Zhao
Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
---
tools/libxl/libxl_arm.c | 8 +---
tools/libxl/libxl_arm.h | 11 +++
2 files changed, 12 insertions(+), 7 deletions(-)
From: Shannon Zhao
Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
address of ACPI tables from it.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
---
docs/misc/arm/device-tree/acpi.txt | 24
tools/libxl/libxl_arm.c| 24 +
flight 100706 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 14 guest-stop fail REGR. vs. 100674
Regressions which
flight 100708 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 100704
Regre
flight 100709 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100709/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ef3209d3028b77af9f56f183370e7b67cd7c849
baseline version:
ovmf b10d5ddc0385f39d2c2c6
On 08/31/2016 12:15 PM, Sebastian Andrzej Siewior wrote:
> On 2016-08-26 15:37:38 [-0400], Boris Ostrovsky wrote:
>>> If you do find the time, you might manage to rework the code to avoid
>>> using the _nocalls() function. If see this right, you use
>>> xen_setup_vcpu_info_placement() for the init
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:39 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 5/6]
On Thu, 1 Sep 2016, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 01, 2016 at 02:11:31PM +0200, Olaf Hering wrote:
> > Implement SUSE specific unplug protocol for emulated PCI devices
> > in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> > This protocol was implemented and used since Xen 3.0
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:30 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 4/6]
Wei Liu, on Tue 30 Aug 2016 14:57:50 +0100, wrote:
> On Tue, Aug 30, 2016 at 01:51:23PM +0200, Juergen Gross wrote:
> > Mini-OS applications being compiled using Mini-OS headers without
> > being integrated in the make environment of Mini-OS need a way to set
> > CONFIG_* defines according to their
Hello,
Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
> I stumbled over the problem with xenstore-stubdom: xenstore is using
> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
> build error with Mini-OS (console_evtchn in include/console.h was
> #define'd to console.
On 09/01/2016 08:55 PM, Shannon Zhao wrote:
>
> On 2016/9/1 20:53, Boris Ostrovsky wrote:
>> On 08/31/2016 11:18 PM, Shannon Zhao wrote:
On 2016/8/30 1:46, Julien Grall wrote:
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index d741ac5..7f50a33 100644
On 2016/9/1 20:53, Boris Ostrovsky wrote:
> On 08/31/2016 11:18 PM, Shannon Zhao wrote:
>> >
>> > On 2016/8/30 1:46, Julien Grall wrote:
>>> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
>>> index d741ac5..7f50a33 100644
>>> --- a/tools/libacpi/Makefile
>>> +++
On Thu, Sep 01, 2016 at 02:11:31PM +0200, Olaf Hering wrote:
> Implement SUSE specific unplug protocol for emulated PCI devices
> in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> This protocol was implemented and used since Xen 3.0.4.
> It is used in all SUSE/SLES/openSUSE releases up to
Hey Julien,
On Thu, Sep 01, 2016 at 01:47:05PM +0100, Julien Grall wrote:
> Hi Daniel,
>
> I have heard you became co-maintainer of GRUB. Congratulations for that :).
Thanks a lot!
> We have a couple series (this series and [1]) to allow grub booting
> Xen on ARM that have been waiting on the GR
On Thu, Sep 01, 2016 at 01:46:24AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 22:50, wrote:
> > On Wed, Aug 31, 2016 at 09:46:31AM -0600, Jan Beulich wrote:
> >> >>> On 31.08.16 at 16:59, wrote:
> >> > On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:
This run is configured for baseline tests only.
flight 67622 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67622/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169
baseline v
"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 100704 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100704/
Fai
On Thu, Sep 01, 2016 at 01:41:26AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 21:31, wrote:
> > On Wed, Aug 31, 2016 at 07:01:10AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.16 at 21:58, wrote:
> >> > On Thu, Aug 25, 2016 at 07:27:21AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:
On Thu, Sep 01, 2016 at 01:40:11AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 19:07, wrote:
> > On Wed, Aug 31, 2016 at 06:49:51AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.16 at 21:32, wrote:
> >> > On Thu, Aug 25, 2016 at 06:59:54AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:
On 01/09/16 20:40, Boris Ostrovsky wrote:
> On 09/01/2016 03:35 PM, Andrew Cooper wrote:
>> On 01/09/16 20:27, Boris Ostrovsky wrote:
>>> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
>>> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>>>
>>> I have a
Hi all,
just a quick reminder that tomorrow, Friday the 2nd of September, at 9AM
PST / 5PM UK, there will be a technical community call on PV Calls.
To join the call, visit:
https://www.uberconference.com/stefano-aporeto
The webpage contains information on how to join the call via PC or
telepho
On 09/01/2016 03:35 PM, Andrew Cooper wrote:
> On 01/09/16 20:27, Boris Ostrovsky wrote:
>> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
>> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>>
>> I have a patch that fixes all these warnings but do we wan
On 01/09/16 20:27, Boris Ostrovsky wrote:
> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>
> I have a patch that fixes all these warnings but do we want it or should
> we instead upgrade to latest ipxe
Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
compiling ipxe that is fetched by Xen, mostly due to stricter checks.
I have a patch that fixes all these warnings but do we want it or should
we instead upgrade to latest ipxe version? (It builds fine but I haven't
tested it).
* Use %pv or just d%d in preference to the multiple current ways of
presenting the same information.
* Use PRI_mfn instead of opencoding it.
* Drop all explicit use of __func__ from SHADOW_{PRINTK,DEBUG}() calls. The
wrappers already include it.
* Use hex rather than decimal for printing
This allows printf format checking to be performed, and for
debugtrace_printk() to evaluate its arguments, even if debugtrace is disabled
at compile time.
No intended change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/include/xen/lib.h | 6 -
flight 100690 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail REGR. vs. 100674
Regressions which
cpufeat_mask() yields an unsigned integer constant. As a result, taking its
complement causes zero extention rather than sign extention.
The result is that, when a guest OS has OXSAVE disabled, all features in 1d
are hidden from native CPUID. Amongst other things, this causes the early
code in L
This run is configured for baseline tests only.
flight 67621 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67621/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5322ee484b54bc78023383a546971b601dcc4ce1
baseline v
Windows 8, 10 and Server 2012 guests hang intermittently while booting
on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs, shortly after the Windows
logo appears and the little dots start spinning.
Running strace on qemu shows its main thread doing the following every
couple of milliseconds:
ppoll([...,
flight 100703 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100703/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169
baseline version:
ovmf 5322ee484b54bc7802338
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
---
xen/arch/arm/p2m.c| 71 +--
xen/include/asm-arm/p2m.h | 11
2 files changed, 73 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e85
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
Freeing p2m entries of arbitrary p2m's (in particular in alternate
p2m's) will lead to unpredicted behavior as the entries might still be
used within the host's p2m. The host's p2m should, however, free the
entries, as it is the main insta
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
This commit adopts the x86 HVMOP_altp2m_get_domain_state implementation.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v3: Removed the "altp2m_enabled" check in HVMOP_altp2m_get_domain_state
case a
On 01/09/2016 14:11, Olaf Hering wrote:
> Update unplug in Xen HVM guests to cover more cases.
> Please review.
>
> Olaf
>
> Olaf Hering (2):
> xen_platform: unplug also SCSI disks
> xen_platform: SUSE xenlinux unplug for emulated PCI
>
> hw/i386/xen/xen_platform.c | 36 ++
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
This commit moves the altp2m-related code from x86 to ARM. Functions
s/moves/copies/
However, this is not really true because the code is current patch is
not a verbatim copy.
Lastly, what is the status to have x86 and ARM implementa
flight 100699 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100699/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5322ee484b54bc78023383a546971b601dcc4ce1
baseline version:
ovmf 00afc8f82061677fedc86
This run is configured for baseline tests only.
flight 67620 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67620/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff
baseline v
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
This commit introduces macros for switching and restoring the vttbr
considering the currently set irq flags. We define these macros, as the
following commits will use the associated functionality multiple times
throughout the file ./xen/ar
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
This commit exposes the "p2m_*lock" helpers, as they will be used within
the file ./xen/arch/arm/altp2m.c, as will be shown in the following
commits.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/
Hello Sergej,
On 16/08/16 23:16, Sergej Proskurin wrote:
This commit substitutes the direct access of the host's p2m
(&d->arch.p2m) for the macro "p2m_get_hostp2m". This macro simplifies
the differentiation between the host's p2m and introduced alternative
p2m's, in the following commits.
Signe
flight 100698 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100698/
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 01.09.16 at 16:27, wrote:
> On 24/08/16 16:31, Jan Beulich wrote:
>> Another place where we should try to behave like real hardware; see
>> the code comments.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3358,6 +3358,31 @@ void
Hi,
On 25/08/16 16:11, Jan Beulich wrote:
On 25.08.16 at 15:37, wrote:
On most architectures it does not matter what the aligment is.
On ARM32 it is paramount that the aligment is word-size (4)
otherwise we get a Data Abort when trying to perform ELF
relocations. That is due to ARM 32 only be
>>> On 01.09.16 at 16:37, wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> The less obvious (and potentially controversial) part is that of a call
>> gate with DPL < selector.RPL: Such gates can't be used either without
>> the hardware raising #GP, but the specific case of DPL=0 gets handled
>> i
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.
Either way - we ca
On 29/08/16 14:57, Jan Beulich wrote:
> There are two cases: The obvious one is that system gates with type 0
> shouldn't have what might be their DPL altered - such descriptors can't
> be used anyway without incurring a #GP, and hence adjusting its DPL is
> only risking to confuse the guest.
This
On 24/08/16 16:31, Jan Beulich wrote:
> Another place where we should try to behave like real hardware; see
> the code comments.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
> i
On 01/09/16 15:10, Tamas K Lengyel wrote:
> Extend the CPUID monitor event to include EAX and ECX values that were used
> when CPUID was executed. This is useful in identifying which leaf was queried.
> We also adjust the xen-access output format to more closely resemble the
> output
> of the Linu
On 01/09/16 13:56, Jan Beulich wrote:
On 01.09.16 at 13:23, wrote:
>> On 24/08/16 16:31, Jan Beulich wrote:
>>> Another place where we should try to behave like real hardware; see
>>> the code comments.
>>>
>>> Signed-off-by: Jan Beulich
>>>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arc
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and u
On 09/01/2016 05:10 PM, Tamas K Lengyel wrote:
> Extend the CPUID monitor event to include EAX and ECX values that were used
> when CPUID was executed. This is useful in identifying which leaf was queried.
> We also adjust the xen-access output format to more closely resemble the
> output
> of the
Extend the CPUID monitor event to include EAX and ECX values that were used
when CPUID was executed. This is useful in identifying which leaf was queried.
We also adjust the xen-access output format to more closely resemble the output
of the Linux cpuid tool's raw format.
Signed-off-by: Tamas K Le
On Thu, Sep 1, 2016 at 2:02 AM, Razvan Cojocaru
wrote:
> On 09/01/2016 10:58 AM, Jan Beulich wrote:
> On 01.09.16 at 09:26, wrote:
>>> On 09/01/16 02:52, Tamas K Lengyel wrote:
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -226,6 +226,13 @@ struct v
On Thu, Sep 1, 2016 at 2:01 AM, Jan Beulich wrote:
On 01.09.16 at 01:52, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2402,12 +2402,17 @@ static void vmx_cpuid_intercept(
>> static int vmx_do_cpuid(struct cpu_user_regs *regs)
>> {
>> unsigned i
flight 100697 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100697/
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 100692 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100692/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff
baseline version:
ovmf 950a3bc788b5b101729b2
Hi Konrad,
NIT: title: s/decleration/declaration/
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
On ARM we need an alternative VA region to poke in the
hypervisor .text data. And since this is setup during runtime
we may fail (it uses vmap so most likely error is ENOMEM).
As such this error n
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 6:24 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [PATCH v3 2/6]
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
It was missing 2MB.
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Julien Grall
Regards,
---
Cc: Stefano Stabellini
Cc: Julien Grall
v2: First submission. Spun of from 'livepatch: Initial ARM64 support."
---
xen/include/as
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
This is copied from Linux 4.7, and the initial commit
that put this in is 5c5bf25d4f7a950382f94fc120a5818197b48fe9
"arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions"
This lays the groundwork for Livepatch to generat
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.
Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked do
>>> On 01.09.16 at 13:23, wrote:
> On 24/08/16 16:31, Jan Beulich wrote:
>> Another place where we should try to behave like real hardware; see
>> the code comments.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3358,6 +3358,31 @@ void
On 01/09/16 12:31, Andrew Cooper wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> - There's no 32-bit displacement in 16-bit addressing mode.
>> - It is wrong to ASSERT() anything on parts of an instruction fetched
>> from guest memory.
>> - The two scaling bits of a SIB byte don't affect whethe
>>> On 01.09.16 at 13:31, wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> - There's no 32-bit displacement in 16-bit addressing mode.
>> - It is wrong to ASSERT() anything on parts of an instruction fetched
>> from guest memory.
>> - The two scaling bits of a SIB byte don't affect whether ther
On 08/31/2016 11:18 PM, Shannon Zhao wrote:
>
> On 2016/8/30 1:46, Julien Grall wrote:
>>> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
>>> index d741ac5..7f50a33 100644
>>> --- a/tools/libacpi/Makefile
>>> +++ b/tools/libacpi/Makefile
>>> @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DI
Hi Daniel,
I have heard you became co-maintainer of GRUB. Congratulations for that :).
We have a couple series (this series and [1]) to allow grub booting Xen
on ARM that have been waiting on the GRUB ML for a while to be pushed.
Those patches have been tested and already integrated in some
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH 0/2] Xen HVM unplug changes
Type: series
Message-id: 20160901121131.16007-1-o...@aepfle.de
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline
Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
be used by the emulated BIOS to boot from disk. If the HVM domU has also
PV driver the disk may appear twice in the guest. To avoid this an
unplug of the emulated hardware is needed, similar to what is done for
IDE and NIC drive
Implement SUSE specific unplug protocol for emulated PCI devices
in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
This protocol was implemented and used since Xen 3.0.4.
It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
openSUSE 12.3.
Signed-off-by: Olaf Hering
---
hw/i3
Update unplug in Xen HVM guests to cover more cases.
Please review.
Olaf
Olaf Hering (2):
xen_platform: unplug also SCSI disks
xen_platform: SUSE xenlinux unplug for emulated PCI
hw/i386/xen/xen_platform.c | 36 +++-
1 file changed, 35 insertions(+), 1 deleti
flight 100695 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100695/
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
Hi Stefano,
On 31/08/16 20:33, Stefano Stabellini wrote:
On Wed, 31 Aug 2016, Julien Grall wrote:
@@ -236,28 +238,99 @@ static lpae_t *p2m_get_root_pointer(struct
p2m_domain *p2m,
/*
* Lookup the MFN corresponding to a domain's GFN.
+ * Lookup mem access in the ratrix tree.
+ * The entries
On 29/08/16 14:57, Jan Beulich wrote:
> - There's no 32-bit displacement in 16-bit addressing mode.
> - It is wrong to ASSERT() anything on parts of an instruction fetched
> from guest memory.
> - The two scaling bits of a SIB byte don't affect whether there is no
> scaled index register.
>
> S
On 24/08/16 16:31, Jan Beulich wrote:
> Another place where we should try to behave like real hardware; see
> the code comments.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
> i
This run is configured for baseline tests only.
flight 67619 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67619/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 950a3bc788b5b101729b26aed3ff75fd2a64a570
baseline v
On 17/08/16 18:19, Dario Faggioli wrote:
For get_fallback_cpu(), by putting in place the "usual"
two steps (soft affinity step and hard affinity step)
loop. We just move the core logic of the function inside
the body of the loop itself.
For csched2_cpu_pick(), what is important is to find
the ru
1 - 100 of 137 matches
Mail list logo
