flight 120025 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken in 119952
build-armhf-pvops
On 26/02/18 17:01, Pavel Tatashin wrote:
> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
>
> This is because the xen's PagePinned() flag is getting erased from str
Hi,
I am trying to boot kernel 4.4 on Jacinto-6 EVM board, I am facing error
from xen. Please find attached log to find errors.
The kernel is stuck at
[6.881378] Waiting for root device /dev/mmcblk0p2...
Is it due to i2c related errors in boot log as mentioned below?
[0.831911] palmas 0-
* Pavel Tatashin wrote:
> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
>
> This is because the xen's PagePinned() flag is getting erased from struct
> pages wh
On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
+{
+str
On Tue, Feb 27, 2018 at 11:47:45AM +0530, Anshuman Gupta wrote:
> From: "Luis R. Rodriguez"
>
Anshuman, looks like you sent this by mistake. Please, be careful!
Everyone, kindly ignore this patch.
> ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES
> can be used to determine i
From: "Luis R. Rodriguez"
ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES
can be used to determine if a system has legacy devices LPC or
ISA devices. The x86 platform already has a struct which lists
known associated legacy devices, we start off careful only
by disabling root d
flight 120022 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-lib
In case of errors in irq setup for MSI, free up the allocated irqs.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi
CC:
CC: Roger Pau Monné
CC: David Vrabel
CC: Boris Ostrovsky
CC: Eduardo Valentin
CC: Juergen Gross
CC: Thomas Gleixner
CC: "K.
Hello,
These bugs were found during code review. Details in the commits.
Please review and apply.
CC: Roger Pau Monné
CC: David Vrabel
CC: Boris Ostrovsky
CC: Eduardo Valentin
CC: Juergen Gross
CC: Thomas Gleixner
CC: "K. Y. Srinivasan"
CC: Liu Shuo
CC: Anoob Soman
Amit Shah (2):
x
When an MSI descriptor was not available, the error path would try to
unbind an irq that was never acquired - potentially unbinding an
unrelated irq.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi
CC:
CC: Roger Pau Monné
CC: David Vrabel
CC: Boris
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 3:11 AM
>
> On 26/02/18 11:25, Jan Beulich wrote:
> On 20.02.18 at 12:58, wrote:
> >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the
> value in
> >> MSR_TSC_AUX, irrespective of
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, February 26, 2018 5:57 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 24 February 2018 02:57
> > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > Cc: Stefano Stabellini
flight 120051 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120051/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> Dispatch from the guest_{rd,wr}msr() functions, after falling through from
> the
> !is_viridian_domain() case.
>
> Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for
> consistenc
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> Dispatch from the guest_{rd,wr}msr() functions, after confirming that the
> domain is configured to use viridian. This allows for simplifiction of the
> viridian helpers as they don't need to c
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 27, 2018 1:35 AM
>
> The default case of vmx_msr_write_intercept() in particular is very tangled.
>
> First of all, fold long_mode_do_msr_{read,write}() into their callers. These
> functions were split out in the
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>> +static struct xen_gem_object *gem_create(struct drm_device *dev,
>>> size_t size)
>>> +{
>>> +struct xen_drm_front_drm_info *drm
On 26/02/2018 19:44, Boris Ostrovsky wrote:
> On 02/26/2018 02:12 PM, Andrew Cooper wrote:
>> On 20/02/18 11:58, Andrew Cooper wrote:
>>> This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
>>> guests. It is RFC because I haven't done extensive testing on the result,
>>> an
flight 120044 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120044/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 02/26/2018 12:36 PM, Amit Shah wrote:
> When an MSI descriptor was not available, the error path would try to
> unbind an irq that was never acquired - potentially unbinding an
> unrelated irq.
>
> Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> Reported-by: Hooman Mirhadi
>
flight 120011 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 119891
Tests which did not s
On 02/20/2018 06:58 AM, Andrew Cooper wrote:
> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> advertised/hidden.
>
> At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if
> TSC_
On 02/26/2018 02:12 PM, Andrew Cooper wrote:
> On 20/02/18 11:58, Andrew Cooper wrote:
>> This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
>> guests. It is RFC because I haven't done extensive testing on the result,
>> and
>> because there are some functional changes for
On 02/26/2018 12:35 PM, Andrew Cooper wrote:
> Dispatch from the guest_{rd,wr}msr() functions, after falling through from the
> !is_viridian_domain() case.
>
> Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for consistency,
> and because the _regs suffix isn't very appropriate.
>
> U
On 02/26/2018 12:35 PM, Andrew Cooper wrote:
> Dispatch from the guest_{rd,wr}msr() functions, after confirming that the
> domain is configured to use viridian. This allows for simplifiction of the
> viridian helpers as they don't need to cope with the "not a viridian MSR"
> case. It also means t
On 20/02/18 11:58, Andrew Cooper wrote:
> This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
> guests. It is RFC because I haven't done extensive testing on the result, and
> because there are some functional changes for the virtualised TSC modes.
>
> Andrew Cooper (5):
>
On 26/02/18 11:25, Jan Beulich wrote:
On 20.02.18 at 12:58, wrote:
>> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value
>> in
>> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
>> advertised/hidden.
>>
>> At the moment, paravirt_ctxt_switch_to()
On 02/26/2018 06:08 AM, Juergen Gross wrote:
> Today the hvc console is added as a preferred console for pv domUs
> only. As this requires a boot parameter for getting dom0 messages per
> default add it for dom0, too.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/xen/enlighten_pv.c | 4 +++-
>
On 12/01/18 16:05, Jan Beulich wrote:
On 12.01.18 at 16:41, wrote:
>> On 12/01/18 11:23, Jan Beulich wrote:
>>> Even it you make .init.data its own section again, some
>>> garbage will remain (mainly due to the trampoline data).
>> That is far easier to spot an isolate, because it is tiny and
On Mo, 2018-02-26 at 18:14 +, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote:
> >
> > In case of errors in irq setup for MSI, free up the allocated irqs.
> >
> > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> > Reported-by: Hooman Mirh
Applications like libvirt may not populate a device devid field,
delegating that to libxl. If needed, the application can later
retrieve the libxl-produced devid. Indeed most devices are handled
this way in libvirt, channel devices included.
This works well when only one channel device is defined,
On 05/02/18 13:01, Jan Beulich wrote:
On 05.02.18 at 13:22, wrote:
>> On 05/02/18 08:57, Jan Beulich wrote:
>> On 02.02.18 at 17:58, wrote:
To match all our other emulation handling.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulic
On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote:
> In case of errors in irq setup for MSI, free up the allocated irqs.
>
> Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> Reported-by: Hooman Mirhadi
> CC:
> CC: Roger Pau Monné
> CC: David Vrabel
> CC: Boris Ostrov
On 05/02/18 13:14, George Dunlap wrote:
> On 02/05/2018 12:56 PM, Jan Beulich wrote:
> On 05.02.18 at 12:55, wrote:
>>> On 02/02/18 08:51, Jan Beulich wrote:
>>> On 01.02.18 at 15:38, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
>>
On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
> (re-sending with xen-devel re-added; not sure how it got lost)
>
> >>> On 23.01.18 at 16:07, wrote:
> > ---
> > tools/tests/vpci/emul.h | 1 +
> > xen/arch/x86/hvm/ioreq.c | 4 +
>
> Again the Cc to Paul is missing (no matter
flight 120010 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 17 guest-localmigrate/x10 fail REGR. vs. 119432
test-amd64-i386-xl-q
The default case of vmx_msr_write_intercept() in particular is very tangled.
First of all, fold long_mode_do_msr_{read,write}() into their callers. These
functions were split out in the past because of the 32bit build of Xen, but it
is unclear why the cases weren't simply #ifdef'd in place.
Next
Dispatch from the guest_{rd,wr}msr() functions, after falling through from the
!is_viridian_domain() case.
Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for consistency,
and because the _regs suffix isn't very appropriate.
Update them to take a vcpu pointer rather than presuming t
Dispatch from the guest_{rd,wr}msr() functions, after confirming that the
domain is configured to use viridian. This allows for simplifiction of the
viridian helpers as they don't need to cope with the "not a viridian MSR"
case. It also means that viridian MSRs which are unimplemented, or exclude
Various changes to MSR handling which don't impact the MSR policy objects
themselves. See individual patches for details.
Andrew Cooper (6):
x86/vmx: Simplfy the default cases in vmx_msr_{read,write}_intercept()
x86/hvm: Handle viridian MSRs via the new guest_{rd,wr}msr() infrastructure
x86
Dispatch from the guest_{rd,wr}msr() functions. The read side should be safe
outside of current context, but the write side is definitely not. As the
toolstack has plausible reason to access the APIC registers via this interface
(not least because whether they are accessible at all depends on gue
The main purpose is to blacklist the Intel Resource Director Technology MSRs.
We do not yet virtualise support for guests, but Linux has been observed to
probe for these MSRs without checking CPUID first.
The architecturally inaccessable ranges don't need to fall back into the
legacy ranges, becau
This is in preparation to make hvm_x2apic_msr_read() take a const vcpu
pointer. One modification is to alter vlapic_get_tmcct() to not use current.
This in turn needs an alteration to hvm_get_guest_time_fixed(), which is safe
because the only mutable action it makes is to take the domain plt lock
Hi,
On 19/02/18 12:39, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> This patch implements the function which is called by Xen when it wants
>> to register the virtual GIC.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> xen/arch/arm/vgic/vgic-init.c | 62
>> +++
Hi,
On 02/26/2018 05:19 PM, Andre Przywara wrote:
Hi,
On 26/02/18 16:57, Julien Grall wrote:
On 02/26/2018 04:48 PM, Andre Przywara wrote:
Hi,
On 23/02/18 18:14, Julien Grall wrote:
On 23/02/18 18:02, Andre Przywara wrote:
Hi,
Hi Andre,
On 19/02/18 12:19, Julien Grall wrote:
Hi,
Hi,
On 26/02/18 16:57, Julien Grall wrote:
>
>
> On 02/26/2018 04:48 PM, Andre Przywara wrote:
>> Hi,
>>
>> On 23/02/18 18:14, Julien Grall wrote:
>>>
>>>
>>> On 23/02/18 18:02, Andre Przywara wrote:
Hi,
>>>
>>> Hi Andre,
>>>
On 19/02/18 12:19, Julien Grall wrote:
> Hi,
>
>
On 02/26/2018 04:58 PM, Andre Przywara wrote:
Hi,
On 19/02/18 12:26, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by th
Hi,
On 19/02/18 12:26, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> When we dump guest state on the Xen console, we also print the state of
>> IRQs that are on a VCPU.
>> Add the code to dump the state of an IRQ handled by the new VGIC.
>>
>> Signed-off-by: Andr
On 02/26/2018 04:48 PM, Andre Przywara wrote:
Hi,
On 23/02/18 18:14, Julien Grall wrote:
On 23/02/18 18:02, Andre Przywara wrote:
Hi,
Hi Andre,
On 19/02/18 12:19, Julien Grall wrote:
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
The VGIC supports virtual IRQs to be connected to a har
On 02/26/2018 01:46 AM, Juergen Gross wrote:
When creating a pthread in xs_watch() try to get the minimal needed
size of the thread from glibc instead of using a constant. This avoids
problems when the library is used in programs with large per-thread
memory.
Use dlsym() to get the pointer to __
Hi,
On 23/02/18 18:14, Julien Grall wrote:
>
>
> On 23/02/18 18:02, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 19/02/18 12:19, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/02/18 14:39, Andre Przywara wrote:
The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
whe
From: Colin King
Date: Fri, 23 Feb 2018 17:16:57 +
> From: Colin Ian King
>
> The function xenvif_rx_skb is local to the source and does not need
> to be in global scope, so make it static.
>
> Cleans up sparse warning:
> drivers/net/xen-netback/rx.c:422:6: warning: symbol 'xenvif_rx_skb'
On 02/26/2018 04:25 PM, Andre Przywara wrote:
Hi,
On 26/02/18 15:55, Julien Grall wrote:
Hi,
On 02/26/2018 03:29 PM, Andre Przywara wrote:
On 13/02/18 16:35, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index f4f2a04a60..9e7fb1edcb 100644
--- a/xen/a
Hi,
On 26/02/18 15:55, Julien Grall wrote:
> Hi,
>
> On 02/26/2018 03:29 PM, Andre Przywara wrote:
>> On 13/02/18 16:35, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index f4f2a04a60..9e7fb1edcb 100644
--- a/xen/arch/arm/vgic/vgic.c
+++
Hi,
On 26/02/18 15:59, Julien Grall wrote:
>
>
> On 02/26/2018 03:16 PM, Andre Przywara wrote:
>> Hi,
>
> Hi,
>
>> forgot to mention:
>>
>> On 13/02/18 14:31, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/02/18 14:39, Andre Przywara wrote:
Processing maintenance interrupts and accessing the l
Hi Kanika,
> On 24 Feb 2018, at 20:40, KANIKA SAINI wrote:
>
> Thank you, Lars.
> The links you have provided have managed to make things clearer to me now.
>
> I understand how a flag in the makefile can be changed by passing a parameter
> to the make command in the command line and how
> "
Hi,
On 26/02/18 16:02, Julien Grall wrote:
> Hi Andre,
>
> On 02/26/2018 03:13 PM, Andre Przywara wrote:
>> Hi,
>>
>> On 13/02/18 14:31, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/02/18 14:39, Andre Przywara wrote:
Processing maintenance interrupts and accessing the list registers
are de
>>> On 26.02.18 at 15:08, wrote:
> Older Xen versions (4.5 and before) might have problems migrating pv
> guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
> suspending zero that MSR and restore it after being resumed.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
>>> On 26.02.18 at 14:11, wrote:
> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
> On 23.02.18 at 19:11, wrote:
>>> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
Signed-off-by: Chao Gao
---
xen/include/public/hvm/hvm_info_table.h | 2 +-
1 file
flight 120014 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 119996
version targeted for testi
Juergen Gross noticed that commit
f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
broke XEN PV domains when deferred struct page initialization is enabled.
This is because the xen's PagePinned() flag is getting erased from struct
pages when they are initialized later in boot.
Changelog
v1 - v2
- Addressed coomment from Juergen Gross: fixed a comment, and moved
after_bootmem from PV framework to x86_init.hyper.
From this discussion:
https://www.spinics.net/lists/linux-mm/msg145604.html
I investigated whether it is feasible to re-enable deferred page
initialization on
Hi Andre,
On 02/26/2018 03:13 PM, Andre Przywara wrote:
Hi,
On 13/02/18 14:31, Julien Grall wrote:
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 spe
On 02/26/2018 03:16 PM, Andre Przywara wrote:
Hi,
Hi,
forgot to mention:
On 13/02/18 14:31, Julien Grall wrote:
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to
Hi,
On 02/26/2018 03:29 PM, Andre Przywara wrote:
On 13/02/18 16:35, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index f4f2a04a60..9e7fb1edcb 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -646,6 +646,38 @@ void gic_inject(void)
Hi,
On 13/02/18 16:35, Julien Grall wrote:
> Hi,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Tell Xen whether a particular VCPU has an IRQ that needs handling
>> in the guest. This is used to decide whether a VCPU is runnable.
>>
>> This is based on Linux commit 90eee56c5f90, written by Eric
Hi,
forgot to mention:
On 13/02/18 14:31, Julien Grall wrote:
> Hi,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Processing maintenance interrupts and accessing the list registers
>> are dependent on the host's GIC version.
>> Introduce vgic-v2.c to contain GICv2 specific functions.
>> Implem
Hi,
On 13/02/18 14:31, Julien Grall wrote:
> Hi,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Processing maintenance interrupts and accessing the list registers
>> are dependent on the host's GIC version.
>> Introduce vgic-v2.c to contain GICv2 specific functions.
>> Implement the GICv2 specif
flight 120002 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120002/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On Mon, Feb 26, 2018 at 01:08:05PM +, Andrew Cooper wrote:
> On 26/02/18 12:31, Roger Pau Monné wrote:
> > On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote:
> >> Newer versions of binutils are capable of emitting an exact number bytes
> >> worth
> >> of optimised nops. Use this i
On Mon, Feb 26, 2018 at 08:33:23PM +0800, Chao Gao wrote:
> On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote:
> On 24.02.18 at 06:49, wrote:
> >> On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote:
> >>>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote:
> I
On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
On 23.02.18 at 19:11, wrote:
>> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>>> Signed-off-by: Chao Gao
>>> ---
>>> xen/include/public/hvm/hvm_info_table.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
On Mon, Feb 26, 2018 at 06:04:51AM -0700, Jan Beulich wrote:
> >>> On 26.02.18 at 13:48, wrote:
> > On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote:
> >> On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote:
> >> > int pt_update_irq(struct vcpu *v)
> >> > {
> >> > struct
On Mon, Feb 26, 2018 at 11:35:00AM +, Andrew Cooper wrote:
> * On the C side, switch to using local lables rather than hardcoded numbers.
> * Rename parameters and lables to be consistent with alt_instr names, and
>consistent between the the C and asm versions.
> * On the asm side, facto
Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
arch/x86/xen/suspend.c | 16
On 26/02/18 14:11, Jan Beulich wrote:
On 26.02.18 at 13:36, wrote:
>> On 26/02/18 11:49, Jan Beulich wrote:
>> On 26.02.18 at 11:18, wrote:
If this is the case I believe the easiest solution would be to let the
kernel set the MSR again after leaving suspended state. suspend/res
Hi Juergen,
Thank you for taking a look at this patch, I will address your
comments, and send out an updated patch.
>> extern void default_banner(void);
>>
>> +static inline void paravirt_after_bootmem(void)
>> +{
>> + pv_init_ops.after_bootmem();
>> +}
>> +
>
> Putting this in the paravirt
On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote:
On 24.02.18 at 06:49, wrote:
>> On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote:
>>>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote:
Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Softwa
On 23/02/18 08:36, Jan Beulich wrote:
> ... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly
> says that the function returns 0 for unrecognized MSRs, so
> {svm,vmx}_msr_write_intercept() should not convert this into success. We
> don't want to unconditionally fail the access though
>>> On 26.02.18 at 13:36, wrote:
> On 26/02/18 11:49, Jan Beulich wrote:
> On 26.02.18 at 11:18, wrote:
>>> If this is the case I believe the easiest solution would be to let the
>>> kernel set the MSR again after leaving suspended state. suspend/resume
>>> require hooks in pv kernels after a
flight 120001 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119713
test-amd64-amd64-xl-qemut-win7-amd64
On Mon, Feb 26, 2018 at 3:51 PM, Julien Grall wrote:
> Hi,
>
> What I meant by using '>' for quoting is all my reply should be prefixed
> with '>'. You write your reply normally.
>
> You can do that in gmail by switching the e-mail from HTML to plain text.
>
Ok. Got it.
> On 26/02/18 07:31, bharat
On 26/02/18 12:31, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote:
>> Newer versions of binutils are capable of emitting an exact number bytes
>> worth
>> of optimised nops. Use this in preference to .skip when available.
>>
>> Signed-off-by: Andrew Cooper
>>> On 26.02.18 at 13:48, wrote:
> On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote:
>> On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote:
>> > int pt_update_irq(struct vcpu *v)
>> > {
>> > struct list_head *head = &v->arch.hvm_vcpu.tm_list;
>> > +LIST_HEAD(purged);
On Mon, Feb 26, 2018 at 01:47:38AM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 23, 2018 at 10:39:20PM -0600, Doug Goldstein wrote:
> > On 2/22/18 11:12 PM, Tian, Kevin wrote:
> > >> From: Wei Liu
> > >> Sent: Thursday, February 22, 2018 5:47 AM
> > >>
> > >> Hi all
> > >>
> > >> At some
On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote:
> On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote:
> > Execute periodic_time callbacks even if the interrupt is not actually
> > injected because the IRQ is masked.
> >
> > Current callbacks from emulated timer devices only u
On Sat, Feb 24, 2018 at 03:23:48AM +, Tian, Kevin wrote:
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Saturday, February 24, 2018 12:08 AM
> >
> > On Fri, Feb 23, 2018 at 05:12:05AM +, Tian, Kevin wrote:
> > > > From: Wei Liu
> > > > Sent: Thursday, February 22, 2018 5:47 AM
>
On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote:
> Execute periodic_time callbacks even if the interrupt is not actually
> injected because the IRQ is masked.
>
> Current callbacks from emulated timer devices only update emulated
> registers, which from my reading of the specs shou
On 26/02/18 11:49, Jan Beulich wrote:
On 26.02.18 at 11:18, wrote:
>> On 26/02/18 10:44, Jan Beulich wrote:
>>> if running PV Linux on older Xen (4.5 and earlier) is relevant, it may be
>>> necessary to use a mechanism other than IBRS to mitigate Spectre v2
>>> on Skylake. That is because the
On 26/02/18 13:06, Andrii Anisov wrote:
> Hello Juergen,
>
>
> On 26.02.18 13:08, Juergen Gross wrote:
>> Today the hvc console is added as a preferred console for pv domUs
>> only. As this requires a boot parameter for getting dom0 messages per
>> default add it for dom0, too.
>>
>> Signed-off-b
On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote:
> Newer versions of binutils are capable of emitting an exact number bytes worth
> of optimised nops. Use this in preference to .skip when available.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wi
On Mon, Feb 26, 2018 at 11:24:55AM +, Andrew Cooper wrote:
> The correct amount of padding in an origin patch site can be calculated
> automatically, based on the relative lengths of the replacements.
>
> This requires a bit of trickery to calculate correctly, especially in the
> ALTENRATIVE_2
Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum
thread stack size for watch thread"):
> It is already enclosed in CONFIG_Linux. I think that should be enough.
Oh, I see. I had read USE_DLSYM as CONFIG_DLSYM, ie "dlsym is
available". A better name might be USE_DLSY
Wei Liu writes ("Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static
shared memory areas during domain destruction"):
> On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote:
> > In any case, the worst that could happen is the unmap is called twice on the
> > same region. So you
Hello Juergen,
On 26.02.18 13:08, Juergen Gross wrote:
Today the hvc console is added as a preferred console for pv domUs
only. As this requires a boot parameter for getting dom0 messages per
default add it for dom0, too.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 4 +++-
On Mon, Feb 26, 2018 at 12:03:29PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get
> minimum thread stack size for watch thread"):
> > I don't think FreeBSD needs this particular workaround for glibc FWIW.
>
> Indeed.
>
> Err, I guess we should
Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum
thread stack size for watch thread"):
> I don't think FreeBSD needs this particular workaround for glibc FWIW.
Indeed.
Err, I guess we should have a configure test of some kind then ?
The patch looks good.
Ian.
___
Hello Dario,
On 22.02.18 19:53, Dario Faggioli wrote:
As I said already, improving the accounting would be more than welcome.
If you're planning on doing something like this already, I'll be happy
to look at the patches. :-)
First I have to document my findings and make some conclusions about
a
Marek Marczykowski-Górecki writes ("Re: [Xen-devel] libxl - avoid calling block
script"):
> On Fri, Feb 09, 2018 at 11:03:55AM +, Roger Pau Monné wrote:
> > Really adding Ian and Wei.
> >
> > On Fri, Feb 09, 2018 at 10:55:24AM +, Roger Pau Monné wrote:
> > > So the problem is creation tim
1 - 100 of 163 matches
Mail list logo