On 22/04/17 03:21, Geliang Tang wrote:
> Use offset_in_page() macro instead of open-coding.
>
> Signed-off-by: Geliang Tang
Pushed to xen/tip for-linus-4.12
Thanks,
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/x
ce id =
>> 0x900, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>> (XEN) [2017-04-24 21:20:49.671] AMD-Vi: Setup I/O page table: device id =
>> 0x901, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>> (XEN) [2017-04-24 21:20:49.687
On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall wrote:
> 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
Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid
values for xsave") introduced a regression as it tried to make use of
the fixup feature before it being available.
Fall back to the old variant testing via cpuid().
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.
On Mon, 24 Apr 2017 16:44:53 -0700 (PDT)
Stefano Stabellini wrote:
> On Mon, 24 Apr 2017, Peter Maydell wrote:
> > On 24 April 2017 at 22:25, Stefano Stabellini
> > wrote:
> > > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> > > new file mode 100644
> > > index 000..18f0ec0
> > >
On 25/04/17 08:35, Sander Eikelenboom wrote:
> On 25/04/17 08:14, Juergen Gross wrote:
>> On 24/04/17 22:15, Boris Ostrovsky wrote:
>>> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
On 24/04/17 17:49, Boris Ostrovsky wrote:
> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>> Hi
flight 107635 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107635/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail
like 107619
test-armhf-armhf-libvirt
On 25/04/17 08:14, Juergen Gross wrote:
> On 24/04/17 22:15, Boris Ostrovsky wrote:
>> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
>>> On 24/04/17 17:49, Boris Ostrovsky wrote:
On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
> Hi Boris,
>
> Nope, not that i am aware of.
>>>
On 24/04/17 22:15, Boris Ostrovsky wrote:
> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
>> On 24/04/17 17:49, Boris Ostrovsky wrote:
>>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
Hi Boris,
Nope, not that i am aware of.
>>> If you can keep console while running this, can
On 25/04/17 00:15, Martin K. Petersen wrote:
>
> Juergen,
>
>> On 22/04/17 03:21, Geliang Tang wrote:
>>> Use offset_in_page() macro instead of open-coding.
>>>
>>> Signed-off-by: Geliang Tang
>>
>> Reviewed-by: Juergen Gross
>
> Taking this through the Xen tree or should I queue it?
I can ta
flight 107637 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107637/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a5ae661754625b8f4bba39214006e87216747e9
baseline version:
ovmf dd29d8b3565ba8ae2e71c
On 24/04/17 20:21, Boris Ostrovsky wrote:
> On 04/24/2017 01:58 PM, Julien Grall wrote:
>> The helper xen_reboot will be called by the EFI code in a later patch.
>>
>> Note that the ARM version does not yet exist and will be added in a
>> later patch too.
>>
>> Signed-off-by: Julien Grall
>
> I d
flight 107633 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Regressions which are
flight 107630 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On Mon, 24 Apr 2017, Peter Maydell wrote:
> On 24 April 2017 at 22:25, Stefano Stabellini wrote:
> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> > new file mode 100644
> > index 000..18f0ec0
> > --- /dev/null
> > +++ b/hw/9pfs/xen-9pfs.h
> > @@ -0,0 +1,14 @@
> > +/*
> > + * Xen 9p b
Juergen,
> On 22/04/17 03:21, Geliang Tang wrote:
>> Use offset_in_page() macro instead of open-coding.
>>
>> Signed-off-by: Geliang Tang
>
> Reviewed-by: Juergen Gross
Taking this through the Xen tree or should I queue it?
--
Martin K. Petersen Oracle Linux Engineering
__
On 24 April 2017 at 22:25, Stefano Stabellini wrote:
> diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> new file mode 100644
> index 000..18f0ec0
> --- /dev/null
> +++ b/hw/9pfs/xen-9pfs.h
> @@ -0,0 +1,14 @@
> +/*
> + * Xen 9p backend
> + *
> + * Copyright Aporeto 2017
> + *
> + * Author
Julien,
We will also need another type of application: one which is
periodically called by XEN itself, not actually servicing any domain
request. This is needed for a
coprocessor sharing framework scheduler implementation.
>>>
>>> EL0 apps can be a powerful new tool for us to u
On Mon, 24 Apr 2017, Peter Maydell wrote:
> On 21 April 2017 at 21:14, Stefano Stabellini wrote:
> > The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:
> >
> > Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +)
> >
> > are available in the git repository
Hello Julien,
3. Some degree of protection. Bug in EL0 handler will not bring down
whole hypervisor.
>>>
>>> If you have a single app handling all the domains using SMC, then you
>>> will
>>> bring down all thoses domains. I agree it does not take down the
>>> hypervisor,
>>> but it
flight 107629 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 3 host-install(3)broken REGR. vs. 107610
test-arm64-arm64-
On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
> On 24/04/17 17:49, Boris Ostrovsky wrote:
>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>>> Hi Boris,
>>>
>>> Nope, not that i am aware of.
>> If you can keep console while running this, can you add these changes
>> and see if we ever unbin
On Mon, 24 Apr 2017, Julien Grall wrote:
> When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
> trace [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machine_restart) will first try to use EFI restart method.
>
> However, the EFI
On Mon, Apr 24, 2017 at 12:40:07PM +0200, Thomas Huth wrote:
> On 20.12.2016 18:43, Eduardo Habkost wrote:
> > This moves the KVM and Xen files to the an accel/ subdir.
> >
> > Instead of moving the *-stubs.c file to accel/ as-is, I tried to
> > move most of the stub code to libqemustub.a. This wa
On Mon, 24 Apr 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch added
> ---
> arch/arm/xen/enlighten.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/xen/e
Hi Russell,
Given the outstanding regression we need to fix as soon as possible,
I'll queue these patches on the xentip tree for 4.12.
Please shout if you disagree.
Thank you.
- Stefano
On Wed, 19 Apr 2017, Stefano Stabellini wrote:
> Hello Russell,
>
> Can I have your acked-by on the follow
Hi Andrii,
On 24/04/2017 17:56, Andrii Anisov wrote:
On 21.04.17 23:58, Stefano Stabellini wrote:
On Fri, 21 Apr 2017, Andrii Anisov wrote:
We will also need another type of application: one which is
periodically called by XEN itself, not actually servicing any domain
request. This is needed f
On Mon, 24 Apr 2017, Thomas Huth wrote:
> On 20.12.2016 18:43, Eduardo Habkost wrote:
> > This moves the KVM and Xen files to the an accel/ subdir.
> >
> > Instead of moving the *-stubs.c file to accel/ as-is, I tried to
> > move most of the stub code to libqemustub.a. This way the obj-y
> > logic
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform devic
On 04/24/2017 12:00 PM, Boris Ostrovsky wrote:
Also, from the description in the SDM, PC flag bit it seems very
disruptive to me.
SDM says that if the bit is set then the processor toggles the PMi pin
(generating a performance monitoring interrupt?)
every time the event occurs. So if we program
This run is configured for baseline tests only.
flight 71224 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 10 guest-start
On 04/24/2017 01:58 PM, Julien Grall wrote:
> When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
> trace [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machine_restart) will first try to use EFI restart method.
>
> However, the EFI
On 04/24/2017 01:58 PM, Julien Grall wrote:
> The helper xen_reboot will be called by the EFI code in a later patch.
>
> Note that the ARM version does not yet exist and will be added in a
> later patch too.
>
> Signed-off-by: Julien Grall
I don't think these changes are worth a whole patch. They
On Mon, 24 Apr 2017, Andrii Anisov wrote:
> On 21.04.17 23:58, Stefano Stabellini wrote:
> > Hello Andrii,
> >
> > could you please use plain text (not HTML) in your emails?
> My bad. Will be checking delivery format settings carefully.
>
> > On Fri, 21 Apr 2017, Andrii Anisov wrote:
> > > We wil
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
arch/arm/xen/enlighten.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 81e3217b12d3..ba7f4c8f5c3e 100644
--- a/arch/arm/x
When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
trace [1].
This is happening because when EFI runtimes are enabled, the reset code
(see machine_restart) will first try to use EFI restart method.
However, the EFI restart code is expecting the reset_system callback to
Hi all,
This small patch series implements EFI reset_system callback when using EFI
Xen. Without this, it will not be possible to reboot/power off ARM64 DOM0
when using ACPI.
Cheers,
Cc: Boris Ostrovsky
Cc: Juergen Gross
Julien Grall (3):
xen: Export xen_reboot
arm/xen: Consolidate calls
The helper xen_reboot will be called by the EFI code in a later patch.
Note that the ARM version does not yet exist and will be added in a
later patch too.
Signed-off-by: Julien Grall
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x.
This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.
The tests are curren
This patch series adds tests to validate VPMU functionality on x86. The tests
write and read PMU MSRs to make sure that that they have been exposed
correctly.
This patch adds Intel PMU MSR addresses as macros for VPMU testing
Signed-off-by: Mohit Gambhir
---
arch/x86/include/arch/msr-index.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/include/arch/msr-index.h
b/arch/x86/include/arch/msr-index.h
index 2e90079..3a79025 100
On 04/24/2017 01:46 PM, Mohit Gambhir wrote:
This patch adds Intel PMU MSR addresses as macros for VPMU testing
Signed-off-by: Mohit Gambhir
---
arch/x86/include/arch/msr-index.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/include/arch/msr-index.h
b/arch/x86/i
This patch adds Intel PMU MSR addresses as macros for VPMU testing
Signed-off-by: Mohit Gambhir
---
arch/x86/include/arch/msr-index.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/include/arch/msr-index.h
b/arch/x86/include/arch/msr-index.h
index 2e90079..3a79025 100
This patch series adds tests to validate VPMU functionality on x86. The tests
write and read PMU MSRs to make sure that that they have been exposed
correctly.
This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.
The tests are curren
On 04/21/2017 05:43 AM, Wei Liu wrote:
On Thu, Apr 20, 2017 at 04:40:08PM -0400, Mohit Gambhir wrote:
This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write
On 04/21/2017 02:31 AM, Jan Beulich wrote:
On 20.04.17 at 22:40, wrote:
--- a/arch/x86/include/arch/msr-index.h
+++ b/arch/x86/include/arch/msr-index.h
@@ -38,6 +38,17 @@
#define MSR_GS_BASE 0xc101
#define MSR_SHADOW_GS_BASE 0xc102
+#define MSR_
flight 107628 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107628/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-libvirt 9 debian-install fail in 107619 pass in 107628
test-amd64-i386-xl-qemut-debianh
On 24/04/17 18:13, Andrew Cooper wrote:
This avoids the log message being followed by
<1>mm.c:5374:d0v0 could not get_page_from_l1e()
Signed-off-by: Andrew Cooper
Release-acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
CC: Julien Grall
---
xen/arch/x86/mm.c | 2 +-
1 file chang
This avoids the log message being followed by
<1>mm.c:5374:d0v0 could not get_page_from_l1e()
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Julien Grall
---
xen/arch/x86/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
ind
This run is configured for baseline tests only.
flight 71225 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71225/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dd29d8b3565ba8ae2e71c097a95b22af5d1d90a4
baseline v
On 21.04.17 23:58, Stefano Stabellini wrote:
Hello Andrii,
could you please use plain text (not HTML) in your emails?
My bad. Will be checking delivery format settings carefully.
On Fri, 21 Apr 2017, Andrii Anisov wrote:
We will also need another type of application: one which is periodicall
Stefano,
On 22.04.17 00:24, Stefano Stabellini wrote:
The key is to be simple. If it becomes complex, then we are reinventing
stubdoms.
If the workload needs hardware access, periodical scheduling and it's
only once instance for all domains, then it's probably better as a
stubdom.
If the work
Stefano,
On 22.04.17 00:24, Stefano Stabellini wrote:
The idea is basically to register an MMIO range to emulate, submit the
request to the EL0 app, which would take care of the emulation. The
interface with Xen would be mostly limited to map/unmap guest memory
(only the guest it is servicing)
On 24/04/17 17:49, Boris Ostrovsky wrote:
> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>> Hi Boris,
>>
>> Nope, not that i am aware of.
>
> If you can keep console while running this, can you add these changes
> and see if we ever unbind the work vector (you can even add dump_stack()
> in _
On Mon, Apr 24, 2017 at 2:41 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 21/04/17 19:44, Oleksandr Tyshchenko wrote:
>>
>> On Fri, Apr 21, 2017 at 7:27 PM, Julien Grall
>> wrote:
>>>
>>> On 21/04/17 15:18, Oleksandr Tyshchenko wrote:
On Wed, Apr 19, 2017 at 8:46 PM,
>>> On 24.04.17 at 17:44, wrote:
> On 04/21/2017 03:14 AM, Jan Beulich wrote:
> On 20.04.17 at 19:49, wrote:
>>> This patch changes wrmsrl() calls to write to MSR_P6_EVTSEL register in the
>>> VPMU to wrmsr_safe(). There are known (and possibly some unknown) cases
>>> where
>>> setting certa
On 21/04/17 17:13, Boris Ostrovsky wrote:
> 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
Reviewed-by: Juerge
>
> Also, from the description in the SDM, PC flag bit it seems very
> disruptive to me.
> SDM says that if the bit is set then the processor toggles the PMi pin
> (generating a performance monitoring interrupt?)
> every time the event occurs. So if we program the counter to count
> "unhaulted cor
flight 107631 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107631/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
>>> On 24.04.17 at 16:24, wrote:
> On Mon, Apr 24, 2017 at 06:39:38AM -0600, Jan Beulich wrote:
>> >>> On 10.04.17 at 15:27, wrote:
>> > Move all the PV specific code along with the supporting code to
>> > pv/domain.c.
>>
>> Had you done this series in a different order, or had the earlier
>> pa
On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
> Hi Boris,
>
> Nope, not that i am aware of.
If you can keep console while running this, can you add these changes
and see if we ever unbind the work vector (you can even add dump_stack()
in __unbind_from_irq() for good measure)? (I added HHH for
On 04/21/2017 03:14 AM, Jan Beulich wrote:
On 20.04.17 at 19:49, wrote:
This patch changes wrmsrl() calls to write to MSR_P6_EVTSEL register in the
VPMU to wrmsr_safe(). There are known (and possibly some unknown) cases where
setting certain bits in MSR_P6_EVTSEL reg. can cause a General Prot
Hi Roger,
On 20/04/17 16:17, Roger Pau Monne wrote:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
new file mode 100644
index 00..aea6c68907
--- /dev/null
+++ b/xen/drivers/vpci/msi.c
@@ -0,0 +1,469 @@
+/*
+ * Handlers for accesses to the MSI capability structure.
+ *
+ * C
Hi Wei Liu,
Thanks for your comments.
On 12 April 2017 at 22:03, Wei Liu wrote:
> On Mon, Apr 03, 2017 at 03:14:31PM +0530, Bhupinder Thakur wrote:
>> Xenconsole supports only PV console currently. To get access to emulated
>> pl011
>> uart another backend console is required.
>>
>> This patch
On Mon, Apr 24, 2017 at 04:10:14AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:27, wrote:
> > We want to have a single entry point to initialise hvm guest. The
> > timing to set hap bit and create per domain mapping is deferred, but
> > that's not a problem.
> >
> > No functional change.
>
Hi Roger,
On 20/04/17 16:17, Roger Pau Monne wrote:
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_
On Mon, Apr 24, 2017 at 06:39:38AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:27, wrote:
> > Move all the PV specific code along with the supporting code to
> > pv/domain.c.
>
> Had you done this series in a different order, or had the earlier
> patches moved their broken out functions rig
Hi Boris,
Nope, not that i am aware of.
--
Sander
On 24/04/17 16:17, Boris Ostrovsky wrote:
> On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
>> Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.
>>
>>
>> Hi Boris / Juergen,
>>
>> This morning i got this dom0 kernel crash
On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
> Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.
>
>
> Hi Boris / Juergen,
>
> This morning i got this dom0 kernel crash (it occurred sporadically
> before (during 4.11), but i didn't have serial console enabled at that
> t
flight 107624 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107624/
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
build-i386-xsm
On Mon, Apr 24, 2017 at 06:41:10AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:27, wrote:
> > There is only one function arch_set_info_hvm_guest is moved. The
> > check_segment function is also moved since arch_set_info_hvm_guest is
> > the only user.
> >
> > No functional change.
> >
> >
On Mon, Apr 24, 2017 at 06:29:20AM -0600, Jan Beulich wrote:
> >>> On 24.04.17 at 12:42, wrote:
> > On Mon, Apr 24, 2017 at 03:51:42AM -0600, Jan Beulich wrote:
> >> >>> On 10.04.17 at 15:27, wrote:
> >> > Use the correct vcpuop name and delete on trailing white space.
> >
> > There is a typo. I
>>> On 10.04.17 at 15:27, wrote:
> There is only one function arch_set_info_hvm_guest is moved. The
> check_segment function is also moved since arch_set_info_hvm_guest is
> the only user.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
Same comment regarding the o
>>> On 10.04.17 at 15:27, wrote:
> Move all the PV specific code along with the supporting code to
> pv/domain.c.
Had you done this series in a different order, or had the earlier
patches moved their broken out functions right away, this patch
would have been quite a bit smaller. Anyways, it look
>>> On 24.04.17 at 12:42, wrote:
> On Mon, Apr 24, 2017 at 03:51:42AM -0600, Jan Beulich wrote:
>> >>> On 10.04.17 at 15:27, wrote:
>> > Use the correct vcpuop name and delete on trailing white space.
>
> There is a typo. It should be:
>
> delete *one* trailing ...
I did notice it, but it didn
Hello,
Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch
series allows using it for a PVH Dom0, which seems to be required in order to
boot on older boxes.
This series is RFC because IMHO in part it's just masking a more severe
underlying issue that I've seen while trying
This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/dom0_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 4
On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
trying to boot a PVH Dom0 will freeze the box completely, up to the point that
not even the watchdog works. The freeze happens exactly when enabling the DMA
remapping in the IOMMU, the last line seen is:
(XEN) [VT-D]iommu_
They are emulated by Xen, so they must not be mapped into Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/dom0_build.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
i
Make sure the reserved regions are setup before enabling the DMA remapping in
the IOMMU, by calling dom0_setup_permissions before iommu_hwdom_init. Also, in
order to workaround IOMMU issues seen on pre-Haswell Intel hardware, make sure
the DMA remapping is enabled after populating Dom0 p2m.
Signed
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 April 2017 12:03
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com;
> boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v2 1/9] xen/vpci: introduce
Hi Oleksandr,
On 21/04/17 19:44, Oleksandr Tyshchenko wrote:
On Fri, Apr 21, 2017 at 7:27 PM, Julien Grall wrote:
On 21/04/17 15:18, Oleksandr Tyshchenko wrote:
On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall
wrote:
Aha. Seems, I understand what you meant. I already have a check in IPMMU dr
Hi Jan,
On 21/04/17 17:01, Jan Beulich wrote:
On 21.04.17 at 16:36, wrote:
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1083,7 +1083,7 @@ wait descriptor timed out', try increasing this value.
### iommu\_inclusive\_mapping (VT-d)
> `= `
-> Default:
flight 71223 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-sid-netboot-pvgrub 9 debian-di-install fail REGR. vs.
71198
Regre
On Mon, Apr 24, 2017 at 03:57:42AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:27, wrote:
> > +int vcpu_initialise(struct vcpu *v)
> > +{
> > +struct domain *d = v->domain;
> > +int rc;
> > +
> > +v->arch.flags = TF_kernel_mode;
> > +
> > +rc = mapcache_vcpu_init(v);
> > +
On Mon, Apr 24, 2017 at 11:19:10AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 24 April 2017 11:09
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com;
> > boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu
> > ; Jan
On 21/04/17 19:35, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 21 April 2017 at 20:38, Julien Grall wrote:
3. Some degree of protection. Bug in EL0 handler will not bring down
whole hypervisor.
If you have a single app handling all the domains using SMC, then you will
bring dow
On Mon, Apr 24, 2017 at 03:51:42AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:27, wrote:
> > Use the correct vcpuop name and delete on trailing white space.
There is a typo. It should be:
delete *one* trailing ...
I fixed it in my local copy, but since you want this in right away, it
wou
flight 107621 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 20.12.2016 18:43, Eduardo Habkost wrote:
> This moves the KVM and Xen files to the an accel/ subdir.
>
> Instead of moving the *-stubs.c file to accel/ as-is, I tried to
> move most of the stub code to libqemustub.a. This way the obj-y
> logic for accel/ is simpler: obj-y includes accel/ only i
On 21 April 2017 at 21:14, Stefano Stabellini wrote:
> The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:
>
> Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +)
>
> are available in the git repository at:
>
> git://xenbits.xen.org/people/sstabellini/qem
Hi Jan,
On 24/04/17 10:51, Jan Beulich wrote:
On 10.04.17 at 15:27, wrote:
Use the correct vcpuop name and delete on trailing white space.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
Afaic fine to go in right away (no code change at all). Julien?
Yes, I am happy to see the documentati
On 21/04/17 15:44, Jennifer Herbert wrote:
Hi Julien,
Hello Jenny,
This is extending an existing feature.
Once 4.9 is released, the existing feature will be frozen, and the only
way to later get the
extra functionality would be to created a completely new dm_op, which
does something very si
>>> On 10.04.17 at 15:27, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -533,6 +533,58 @@ static void pv_domain_destroy(struct domain *d)
> free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> }
>
> +static int pv_domain_initialise(struct domain *d, unsigned int
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 April 2017 11:09
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com;
> boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v2 1/9] xen/vpci: introduce
On Mon, Apr 24, 2017 at 10:58:04AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 24 April 2017 10:42
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com;
> > boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu
> > ; Jan
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 April 2017 11:12
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com;
> boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v2 1/9] xen/vpci: introduce
>>> On 10.04.17 at 15:27, wrote:
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 10.04.17 at 15:27, wrote:
> We want to have a single entry point to initialise hvm guest. The
> timing to set hap bit and create per domain mapping is deferred, but
> that's not a problem.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/domain.c | 11 +
1 - 100 of 116 matches
Mail list logo
