On 10/13/16 20:33 +0100, Andrew Cooper wrote:
On 13/10/16 19:59, Dan Williams wrote:
On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
wrote:
On 13/10/16 16:40, Dan Williams wrote:
On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote:
[..]
I think we can do the similar for Xen, like to lay anoth
flight 67877 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail
never pass
test-armhf-armhf-
On Thu, 2016-10-13 at 13:46 +0100, Wei Liu wrote:
> On Thu, Oct 13, 2016 at 01:44:28PM +0100, Dario Faggioli wrote:
> >
> > Ok, so, if that's the case, what's the process: resend (this patch)
> > --
> > or some other kind of formal request-- with secur...@xenproject.org
> > Cc-ed?
> >
>
> If you
On 14/10/16 07:39, Jan Beulich wrote:
On 13.10.16 at 15:46, wrote:
>> Sample error looks like:
>>
>> (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading
>> (entry 13).
>> (XEN) msr 068a, val 1fff80102af0, (mbz 0)
> A _really_ minor remark: This is no longer in
Both explicit PUSH and far CALL currently push unrelated data (the
segment attributes word) in the high half (attributes and limit in the
64-bit case in the high 48 bits) instead of zero. To avoid having to
apply this and further changes in multiple places, also fold the two
(respectively) far call
The high halves of all GPRs are undefined in 32-bit and compat modes,
and the dependency is being obfuscated by our structure field names not
matching architectural register names (it was actually while putting
together a patch to correct this when I noticed the issue here).
For consistency also u
On 14/10/16 10:37, Jan Beulich wrote:
> The high halves of all GPRs are undefined in 32-bit and compat modes,
> and the dependency is being obfuscated by our structure field names not
> matching architectural register names (it was actually while putting
> together a patch to correct this when I no
On 14/10/16 07:36, Jan Beulich wrote:
On 14.10.16 at 02:58, wrote:
>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
>>> There should be a high barrier to "Supported" status, because the cost
>>> of getting it wrong is equally high. However, there are perfectly
>>> legitimate intermediate stages
Hi,
Here's v2.
The differences are:
- review comments taken into account.
- I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
separate patch.
v1 is here:
https://lists.xen.org/archives/html/xen-devel/2016-10/msg00857.html
And there is a git branch for this new version:
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Wei Liu
Cc: Lars Kurth
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
---
Changes from v1:
* file renamed from credit.pandoc to sched_credit.pandoc;
* feature name is now 'Credit Sch
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: Wei Liu
Cc: Lars Kurth
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
---
Changes from v1:
* don't claim 'Supported' status;
* file renamed from credit2.pandoc to
On 14/10/16 10:37, Jan Beulich wrote:
> Both explicit PUSH and far CALL currently push unrelated data (the
> segment attributes word) in the high half (attributes and limit in the
> 64-bit case in the high 48 bits) instead of zero. To avoid having to
> apply this and further changes in multiple pla
Signed-off-by: Dario Faggioli
---
Cc: Meng Xu
Cc: George Dunlap
Cc: Wei Liu
Cc: Lars Kurth
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
---
Changes from v1:
* file renamed from rtds.pandoc to sched_rtds.pandoc;
* feature name is now 'R
>>> On 13.10.16 at 17:40, wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote:
> [..]
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>>
>> Well, my opinion certainly doesn't count much
Contrary to the description in the software manuals, in Long Mode, attempts to
load %cs check that D is not set in combination with L before the present flag
is checked.
This can be observed because the L/D check fails with #GP before the presence
check failes with #NP
Signed-off-by: Andrew Coope
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 24
1 file changed, 24 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ceb89c7..3c90ecd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -20
flight 101429 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-installfail REGR. vs. 101383
test-armhf-armhf-x
>>> On 14.10.16 at 11:59, wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
> On 14.10.16 at 02:58, wrote:
>>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
There should be a high barrier to "Supported" status, because the cost
of getting it wrong is equally high. However, there are perfe
>>> On 13.10.16 at 17:46, wrote:
> On 10/13/16 03:08 -0600, Jan Beulich wrote:
> On 13.10.16 at 10:53, wrote:
>>> On 10/13/16 02:34 -0600, Jan Beulich wrote:
>>> On 12.10.16 at 18:19, wrote:
> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote:
> On 12.10.16 at 17:42, wrote
Signed-off-by: Dario Faggioli
---
This goes on top of:
https://lists.xen.org/archives/html/xen-devel/2016-10/msg00944.html
I'm of course happy to rebase/resend, if the above mentioned series
changes.
---
Cc: secur...@xenproject.org
Cc: George Dunlap
Cc: Anshul Makkar
Cc: Wei Liu
Cc: Lars Kur
flight 101435 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101435/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8
baseline version:
ovmf 08354c34486947da17a36
>>> On 14.10.16 at 12:17, wrote:
> Signed-off-by: Dario Faggioli
I have to admit that I would have expected a non-empty description,
at least briefly rationalizing the change of state.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://l
>>> On 14.10.16 at 12:06, wrote:
> Contrary to the description in the software manuals, in Long Mode, attempts to
> load %cs check that D is not set in combination with L before the present flag
> is checked.
>
> This can be observed because the L/D check fails with #GP before the presence
> chec
>>> On 14.10.16 at 12:06, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 14/10/16 11:28, Jan Beulich wrote:
On 14.10.16 at 12:06, wrote:
>> Contrary to the description in the software manuals, in Long Mode, attempts
>> to
>> load %cs check that D is not set in combination with L before the present
>> flag
>> is checked.
>>
>> This can be observed because the
flight 101436 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 101412
Tests which did not suc
On 14/10/16 11:17, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
We don't have a general framework for declaring things "supported" yet,
and at the moment we only have a single level of "supported", which
includes XSAs. I do think it makes sense to include an assessment of
the security r
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 October 2016 05:38
> To: xen-devel
> Cc: Paul Durrant
> Subject: [PATCH] x86/Viridian: don't depend on undefined register state
>
> The high halves of all GPRs are undefined in 32-bit and compat modes,
> and t
flight 101430 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 9 debian-install fail REGR. vs. 101365
Regressions which
On 12/10/16 19:52, Ronald Rojas wrote:
> Change instances of printf, fprintf, and LOG where the specifier
> used is '%d' to be '%u' for domid.
>
> Signed-off-by: Ronald Rojas
Code looks good, thanks!
A couple of minor adjustments to the patch itself:
First, the traditional "tag" for this would
On 13/10/16 23:19, Jim Fehlig wrote:
> On 09/29/2016 08:54 PM, Dario Faggioli wrote:
>> Last part of the wiring necessary for allowing to
>> change the value of the ratelimit_us parameter online,
>> for Credit2 (like it is already for Credit1).
>>
>> Signed-off-by: Dario Faggioli
>> Reviewed-by: G
>>> On 13.10.16 at 23:09, wrote:
> ---
This is lacking an S-o-b. And it would also be nice if you switched the
bool_t instances to bool as you're touching them anyway.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-de
On 14/10/16 07:20, Jan Beulich wrote:
On 13.10.16 at 15:26, wrote:
>> On 13/10/16 13:57, Jan Beulich wrote:
>>> Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
>>> operands") didn't consider a specific AMD mode: Mis-alignment #GP
>>> faults can be masked on some of their ha
>>> On 13.10.16 at 23:09, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct
> cpu_user_regs *regs)
> /* We only emulate CPUID. */
> if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
On 14/10/16 08:08, Haozhong Zhang wrote:
> On 10/13/16 20:33 +0100, Andrew Cooper wrote:
>> On 13/10/16 19:59, Dan Williams wrote:
>>> On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
>>> wrote:
On 13/10/16 16:40, Dan Williams wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich
> wro
flight 101434 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000
test-amd64-i386-pair
On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
> Hi,
>
> Here's v2.
>
> The differences are:
> - review comments taken into account.
> - I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
>separate patch.
>
> v1 is here:
>
> https://lists.xen.org/archiv
flight 101445 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101445/
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
. snip..
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> new file mode 100644
> index 000..70bac69
> --- /dev/null
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,217 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#i
On Fri, Oct 14, 2016 at 11:06:55AM +0100, Andrew Cooper wrote:
> Contrary to the description in the software manuals, in Long Mode, attempts to
> load %cs check that D is not set in combination with L before the present flag
> is checked.
>
> This can be observed because the L/D check fails with #
On 14/10/16 13:04, Jan Beulich wrote:
On 13.10.16 at 23:09, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct
>> cpu_user_regs *regs)
>> /* We only emulate CPUID. */
>> if ( ( rc = copy_from_use
On 14/10/16 14:24, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
>> Hi,
>>
>> Here's v2.
>>
>> The differences are:
>> - review comments taken into account.
>> - I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
>>separate patch.
>>
>> v1
This run is configured for baseline tests only.
flight 67879 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67879/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8
baseline v
On Mon, Sep 19, 2016 at 12:52:45AM -0500, Suravee Suthikulpanit wrote:
> AVIC introduces two #vmexit handlers:
> * VMEXIT_INCOMP_IPI
> * VMEXIT_DO_NOACCEL
Great.. Can you describe what you are suppose to do with them?
Please keep in mind that the point of the commit description is to
say some
On Mon, Sep 19, 2016 at 12:52:46AM -0500, Suravee Suthikulpanit wrote:
> Add hooks to manage AVIC data structure during vcpu scheduling.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> xen/arch/x86/hvm/svm/avic.c | 82
> +
> xen/arch/x86/hvm/svm/svm.
On Mon, Sep 19, 2016 at 12:52:47AM -0500, Suravee Suthikulpanit wrote:
> Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR,
> and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch
> introduces new interrupt injection code via AVIC backing page.
>
> Also, the AV
On Mon, Sep 19, 2016 at 12:52:48AM -0500, Suravee Suthikulpanit wrote:
> Hook up virtual_intr_delivery_enabled and deliver_posted_intr functions
> when AVIC is enabled.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> xen/arch/x86/hvm/svm/svm.c | 10 ++
> xen/include/asm-x86/hvm/
Hello Jesus,
I’ll get started on debugging my environment right away. Thanks a lot for your
time. I have attached the logs of our IRC meeting today…I’ll email you with my
debugging results soon.
Sent from Mail for Windows 10
From: Jesus M. Gonzalez-Barahona
Sent: Friday, October 14, 2016 11
When the compat hypercall ABI was added for HVM guests (i.e. supporting 32bit
operating systems making hypercalls against a 64bit Xen), an ABI breakage was
introduced for non-compat guests, as the 64bit hypercall index became
truncated to 32 bits.
This has been the case for a very long time, but i
The common hvm_cpuid() code already does this.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
---
xen/arch/x86/hvm/svm/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0e
Drop repeated identical BUILD_BUG_ON()'s
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: George Dunlap
---
xen/arch/x86/x86_64/mm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index b8b6b70..0083beb 1
* Dom0 does now have an arch_config passed.
* hypercall() and smp_alloc_memory() no longer exist.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/setup.c| 6 +-
xen/include/asm-x86/processor.h | 2 --
xen/include/asm-x86/smp.h | 2 --
3 files changed, 1
This avoids needing a translation table between hardware ordering and Xen's
ordering.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 35 +++---
xen/arch/x86/x86_emulate/x86_emulate.h | 4 ++--
2 f
On 10/14/2016 12:02 PM, Andrew Cooper wrote:
> The common hvm_cpuid() code already does this.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
Reviewed-by: Boris Ostrovsky
___
Xen-devel mai
flight 101442 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101442/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad9448408a5d2863db4aa2cb5d1f0d4a27689528
baseline version:
ovmf a2d59ef2912079fe0631f
flight 101448 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101448/
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
The arm64 build for libacpi was broken due to two reasons:
1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
made CONFIG_ARM disappear.
Fix those by:
1. Correctly generate full path for dsdt_anaycpu_arm.c.
2. Incl
It's better to have a explicit error than a build failure returned by
gcc.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
---
tools/libacpi/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 24eb0c2..c1f0af8 100644
--- a/tools/liba
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
---
tools/libacpi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index c1f0af8..18a5cd4 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -9,7 +9,7 @@
# Thi
Wei Liu (3):
libacpi: fix arm64 build
libacpi: require ACPI_BUILD_DIR to be set
libacpi: add back the "G" in "GNU" in licence header
tools/libacpi/Makefile | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
2.1.4
___
Xen-devel
On Fri, Oct 14, 2016 at 7:46 AM, Andrew Cooper
wrote:
> On 14/10/16 13:04, Jan Beulich wrote:
> On 13.10.16 at 23:09, wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct
>>> cpu_user_regs *regs)
>>>
On Fri, Oct 14, 2016 at 04:03:18PM +0100, Andrew Cooper wrote:
> On 14/10/16 14:24, Wei Liu wrote:
> > On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
> >> Hi,
> >>
> >> Here's v2.
> >>
> >> The differences are:
> >> - review comments taken into account.
> >> - I'm *NOT* claiming
On 14/10/16 18:02, Wei Liu wrote:
> Wei Liu (3):
> libacpi: fix arm64 build
> libacpi: require ACPI_BUILD_DIR to be set
> libacpi: add back the "G" in "GNU" in licence header
All Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lis
On 14/10/16 18:05, Kyle Huey wrote:
> On Fri, Oct 14, 2016 at 7:46 AM, Andrew Cooper
> wrote:
>> On 14/10/16 13:04, Jan Beulich wrote:
>> On 13.10.16 at 23:09, wrote:
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1315,16 +1315,20 @@ static int emulate_forced_invalid
QEMU XenServer/XenProject Working group meeting 29th September 2016
===
Attendees
-
David Vrabel
Jennifer Herbert
Ian Jackson
Andrew Cooper
Paul Durrant
Lars Kurth
QEMU depriv
===
DMOP
There has been agreemen
PVH guests don't receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/cpu_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
in
(Resending with proper mailing lists included)
PVH v2 support for unprivileged guests.
Previous version was posted long time ago. Major changes:
1. Drop PVH v1 support
2. Enable ACPI. This allows us to use much more of native code and
results in making this series much simpler (for example, PV
Signed-off-by: Boris Ostrovsky
---
include/xen/interface/elfnote.h| 12 ++-
include/xen/interface/hvm/hvm_vcpu.h | 143 +
include/xen/interface/hvm/start_info.h | 98 ++
3 files changed, 252 insertions(+), 1 deletion(-)
create mode
Signed-off-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e..d6786b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,13
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/platform-pci-unplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c
b/arch/x86/xen/platform-pci-unplug.c
index 90d1b83..33a783c 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/
Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point we cannot use
variables in .bss which is cleared by kernel. We explicitly place
variables that are initialized here int
We are replacing existing PVH guests with new implementation.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 140 ++-
arch/x86/xen/mmu.c | 21 +-
arch/x86/xen/setup.c | 37 +--
arch/x86/xen/smp.c
From: Matt Fleming
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.
Pull the common code out of head_32.S and into pgtable_32.S so that
setup_pgtable_32 can be invoked from both the new Xen entry point and
the existing startup_3
Make sure they don't use these devices since they are not emulated
for unprivileged PVH guest.
Also don't initialize hypercall page for them in init_hvm_pv_info()
since this has already been done.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 24 +---
1 file
Hi Jesus,
Since our last chat here is what I have done. I have created a new
virtualenv with "--no-site-packages" to insure a fresh clean environment. After
I followed your instructions and pulled up my "dir" data. I notice I didn't
have a "bin" directory and researched why. It turns out
On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
wrote:
>From: Matt Fleming
>
>The new Xen PVH entry point requires page tables to be setup by the
>kernel since it is entered with paging disabled.
>
>Pull the common code out of head_32.S and into pgtable_32.S so that
>setup_pgtable_32 can be
On Fri, Oct 14, 2016 at 02:05:13PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
This run is configured for baseline tests only.
flight 67881 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67881/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad9448408a5d2863db4aa2cb5d1f0d4a27689528
baseline v
On Fri, Oct 14, 2016 at 02:05:11PM -0400, Boris Ostrovsky wrote:
> We are replacing existing PVH guests with new implementation.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 14/10/16 19:05, Boris Ostrovsky wrote:
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> new file mode 100644
> index 000..58c477b
> --- /dev/null
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright C 2016, Oracle and/or its affiliates. All rights reserved
On 14/10/16 19:05, Boris Ostrovsky wrote:
> PVH guests don't receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.
Why not? If they don't, they should. As we are providing ACPI anyway,
we should provide all bits of it.
~Andrew
_
On 10/14/2016 02:31 PM, h...@zytor.com wrote:
> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
> wrote:
>> From: Matt Fleming
>>
>> The new Xen PVH entry point requires page tables to be setup by the
>> kernel since it is entered with paging disabled.
>>
>> Pull the common code out of head
On 10/14/2016 02:38 PM, Andrew Cooper wrote:
>> +jmp *%rax
>> +
>> +#else /* CONFIG_X86_64 */
>> +
>> +call setup_pgtable_32
>> +
>> +mov $_pa(initial_page_table), %eax
>> +movl %eax, %cr3
>> +
>> +movl %cr0, %eax
>> +orl $(X86_CR0_PG | X86_CR0_PE), %eax
>> +movl %eax, %
On Fri, 14 Oct 2016, George Dunlap wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
> On 14.10.16 at 02:58, wrote:
> >> On Fri, 14 Oct 2016, Andrew Cooper wrote:
> >>> There should be a high barrier to "Supported" status, because the cost
> >>> of getting it wrong is equally high. However, the
On 10/14/2016 02:41 PM, Andrew Cooper wrote:
> On 14/10/16 19:05, Boris Ostrovsky wrote:
>> PVH guests don't receive ACPI hotplug interrupts and therefore
>> need to monitor xenstore for CPU hotplug event.
> Why not? If they don't, they should. As we are providing ACPI anyway,
> we should provide
On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky
wrote:
>On 10/14/2016 02:31 PM, h...@zytor.com wrote:
>> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
> wrote:
>>> From: Matt Fleming
>>>
>>> The new Xen PVH entry point requires page tables to be setup by the
>>> kernel since it is en
On 14/10/16 19:55, Boris Ostrovsky wrote:
> On 10/14/2016 02:38 PM, Andrew Cooper wrote:
>>> + jmp *%rax
>>> +
>>> +#else /* CONFIG_X86_64 */
>>> +
>>> + call setup_pgtable_32
>>> +
>>> + mov $_pa(initial_page_table), %eax
>>> + movl %eax, %cr3
>>> +
>>> + movl %cr0, %eax
>>> + orl $(X8
On Fri, Oct 14, 2016 at 02:05:14PM -0400, Boris Ostrovsky wrote:
> Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
> page, initialize boot_params, enable early page tables.
>
> Since this stub is executed before kernel entry point we cannot use
> variables in .bss which is cle
On Fri, Oct 14, 2016 at 02:05:15PM -0400, Boris Ostrovsky wrote:
> Make sure they don't use these devices since they are not emulated
> for unprivileged PVH guest.
Which means they would just return 0 ? Or would it get worst since
the in/out would go to the hypervisor which would kill the guest?
>
On 10/14/2016 03:04 PM, h...@zytor.com wrote:
> On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky
> wrote:
>> On 10/14/2016 02:31 PM, h...@zytor.com wrote:
>>> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
>> wrote:
From: Matt Fleming
The new Xen PVH entry point require
On Fri, Oct 14, 2016 at 02:05:17PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/xen/platform-pci-unplug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/platform-pci-unplug.c
> b/a
On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
Perhaps add in here:
PVH is like PV in that there are no PCI devices - which HVM
code would piggyback on to find the Xen PCI platform device and
use its MMIO space to stash the grants in.
For PVH we balloon out memory and stash the
> :) I am now curious as to which bit I missed.
I made these changes.
- Kyle
---
tests/cpuid-faulting/main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/cpuid-faulting/main.c b/tests/cpuid-faulting/main.c
index 3e782a2..221567d 100644
--- a/tests/cpuid-fau
On 10/14/2016 03:14 PM, Konrad Rzeszutek Wilk wrote:
>
>> +
>> +memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
>> +
>> +memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
>> +set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
>> +if (HYPERVISOR_memory_op(XENMEM
On 10/14/2016 03:16 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 02:05:15PM -0400, Boris Ostrovsky wrote:
>> Make sure they don't use these devices since they are not emulated
>> for unprivileged PVH guest.
> Which means they would just return 0 ? Or would it get worst since
> the in/
On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
wrote:
> On a slightly separate note, as you have just been a successful
> guinea-pig for XTF, how did you find it? It is a very new (still
> somewhat in development) system but the project is looking to try and
> improve regression testing in this
On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
hardware support for faulting on cpuid is necessary to emulate support with an
HVM guest.
On PV guests, hardware support is required so that userspace
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by
While we're here, use bool instead of bool_t.
Signed-off-by: Kyle Huey
---
xen/arch/x86/cpu/intel.c| 9 +
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..2e11662 100
On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>
> Perhaps add in here:
>
> PVH is like PV in that there are no PCI devices - which HVM
> code would piggyback on to find the Xen PCI platform device and
> use its MMIO space to
1 - 100 of 112 matches
Mail list logo
