On 04/10/2018 10:31 AM, Jia-Ju Bai wrote:
>
>
>
> On 2018/4/10 22:27, Boris Ostrovsky wrote:
>> On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
>>> pcistub_probe() is never called in atomic context.
>>> This function is only set as ".probe" in struct pci_dri
On 03/08/2018 05:57 AM, Joao Martins wrote:
@@ -372,6 +376,15 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context,
void **rv)
pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk);
+ /* It has P-state dependencies */
+ if (!acpi_processor_get_psd(handle,
On 9/27/18 2:56 PM, Jens Axboe wrote:
> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>> On 27/09/18 16:26, Jens Axboe wrote:
>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>>> Commit a46b53672b2c (&
On 9/27/18 5:37 PM, Jens Axboe wrote:
> On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
>> On 27/09/18 21:06, Boris Ostrovsky wrote:
>>> On 9/27/18 2:56 PM, Jens Axboe wrote:
>>>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>>>> On 27/09/18 16:26
On 11/27/18 3:37 PM, Stefano Stabellini wrote:
> On Tue, 27 Nov 2018, PanBian wrote:
>> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
>>> On 11/21/18 9:07 PM, Pan Bian wrote:
>>>> kfree() is incorrectly used to release the pages allocated
> ---
> arch/x86/xen/enlighten.c | 78
>
> arch/x86/xen/setup.c | 6 ++--
> drivers/xen/balloon.c| 65 ++------
> include/xen/balloon.h| 5
> 4 files changed, 13 insertions(+), 141 deletions(-)
Reviewed-by: Boris Ostrovsky
On 11/19/18 8:59 AM, Juergen Gross wrote:
> arch/x86/xen/spinlock.c includes several headers which are not needed.
> Remove the #includes.
>
> Signed-off-by: Juergen Gross
> ---
Reviewed-by: Boris Ostrovsky
On 12/6/18 4:37 PM, Borislav Petkov wrote:
> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
>> Thanks! I should be able to post a Tested-by next Monday. Boris, are
>> you going to pick it up for 4.21?
> Boris me or Boris O.?
>
> :-)
>
O. ;-)
There are some minor changes in non-x
On 12/6/18 5:11 PM, Paolo Bonzini wrote:
> On 06/12/18 07:04, Maran Wilson wrote:
>> +config PVH
>> +bool "Support for running PVH guests"
>> +---help---
>> + This option enables the PVH entry point for guest virtual machines
>> + as specified in the x86/HVM direct boot ABI.
>> +
On 12/6/18 5:49 PM, Paolo Bonzini wrote:
> On 06/12/18 23:34, Boris Ostrovsky wrote:
>> On 12/6/18 5:11 PM, Paolo Bonzini wrote:
>>
>>> and also
>>>
>>> depends on !EFI
>>>
>>> because even though in principle it would be possible t
On 12/7/18 5:25 AM, Borislav Petkov wrote:
> On Thu, Dec 06, 2018 at 11:14:34PM +0100, Paolo Bonzini wrote:
>>> There are some minor changes in non-xen x86 code so it would be good to
>>> get x86 maintainers' ack.
>> It's not really code, only Kconfig (and I remarked on it just now), but
>> it does
On 07/02/2018 12:02 PM, Mark Rutland wrote:
> On Mon, Jul 02, 2018 at 05:46:55PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 02, 2018 at 04:12:50PM +0100, Mark Rutland wrote:
>>> Users can request that general purpose registers, instruction pointer,
>>> etc, are sampled when a perf event counter ov
On 06/28/2018 06:43 AM, Thomas Gleixner wrote:
>
> For enhanced fun the early calibration stuff was moved from right after
> init_hypervisor_platform() to the place where it is now in commit
> ccb64941f375a6 ("x86/timers: Move simple_udelay_calibration() past
> kvmclock_init()") to speed up KVM boo
On 05/14/2018 08:50 AM, Jan Beulich wrote:
On 09.05.18 at 22:33, wrote:
>> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen)
>> mov %eax,%es
>> mov %eax,%ss
>>
>> +/* Set base address in stack canary descriptor. */
>> +movl _pa(gdt_start),%eax
>> +movl $_pa(canary),%ecx
>> +
On 06/14/2018 04:21 AM, Roger Pau Monné wrote:
> On Wed, Jun 13, 2018 at 07:48:50PM +0100, Ben Hutchings wrote:
>> On Wed, 2018-02-28 at 09:19 +, Roger Pau Monne wrote:
>>> From: Roger Pau Monne
>>>
>>> [ Upstream commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 ]
>>>
>>> Current cleanup in the
On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
> I will go with the change you suggested and
> I'll send v4 tomorrow then.
Please make sure your changes to kbdif.h are in Xen first. I believe you
submitted a patch there but I don't see it in the staging tree yet.
-boris
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
---
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/xen-pvh.S | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen
Fix stack canary handling (in the first patch) and re-index PVH GDT to
make it explicit that the GDT PVH-specific
v3:
- Use GS base MSR for 64-bit mode
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
xen/PVH: Make GDT selectors PVH-specific
arch/x86/xen/xen-pvh.S | 46
On 05/17/2018 11:02 AM, Jan Beulich wrote:
On 17.05.18 at 16:47, wrote:
>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>> mov %eax,%es
>> mov %eax,%ss
>>
>> +mov $PVH_CANARY_SEL,%eax
>> +mov %eax,%gs
> I doubt this is needed for 64-bit (you could equally well load zero or leave
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
A commit message would be useful.
>
> Signed-off-by: Oleksandr Andrushchenko
>
> for (i = 0; i < nr_pages; i++) {
> - page = alloc_page(gfp);
> - if (page == NULL) {
> -
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 49 +++
> include/xen/grant_table.h | 7 ++
> 2 files changed, 56 insertions(+)
>
> diff
On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> drivers/xen/gntdev.c
>>
>> between commit:
>>
>> 1d3145675538 ("xen/gntdev: Make private rou
On 12/12/18 1:09 PM, Maran Wilson wrote:
> On 12/6/2018 1:21 PM, Paolo Bonzini wrote:
>> On 06/12/18 07:02, Maran Wilson wrote:
>>> For certain applications it is desirable to rapidly boot a KVM virtual
>>> machine. In cases where legacy hardware and software support within the
>>> guest is not nee
On 12/18/18 6:28 AM, Andrew Cooper wrote:
> On 18/12/2018 10:42, YueHaibing wrote:
>> On 2018/12/18 16:31, Juergen Gross wrote:
>>> On 18/12/2018 09:19, YueHaibing wrote:
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handl
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
>
> Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Remove flushing of shared buffer on page
On 12/10/18 2:05 PM, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
> Hello, Juergen, Boris!
>
> As this DRM part of the series is the only one which needs ack/nack
>
> (and it might take quite some time to complete) could we please
>
> merge the patches 1 and 3 now that already have ack/r-b?
>
TBH I am not sur
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
> On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
>> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
>>> Hello, Juergen, Boris!
>>>
>>> As this DRM part of the series is the only one which needs ack/nack
&
On 12/10/18 10:12 AM, Andrea Righi wrote:
> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
>
> See also: a50480cb6d61.
>
> Signed-off-by: Andrea Righi
Applied to for-linus-4.21
-boris
On 12/19/18 4:25 PM, Ken Pizzini wrote:
> Since 4.19.5 I have not been able to boot kernels on my Xen-hosted VM on
> a system with an Intel Xeon L5520 processor (microcode 0x1d).
>
> 4.19.4 worked fine; I've tried kernels 4.19.5, 4.19.6, 4.19.7 4.19.9, 4.19.10,
> 4.20-rc7, and they all throw:
>
On 1/2/19 1:58 PM, Souptick Joarder wrote:
> On Mon, Dec 24, 2018 at 6:53 PM Souptick Joarder wrote:
>> Convert to use vm_insert_range() to map range of kernel
>> memory to user vma.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Matthew Wilcox
nused-but-set-variable]
>
> It not used since e6587cdbd732 ("pvcalls-back: set -ENOTCONN in
> pvcalls_conn_back_read")
>
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
and applied to for-linus-4.21.
Thanks.
-boris
Wettstein
[boris: Updated commit message, added Fixes tag]
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org # v4.1+
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront
On 07/11/2018 08:04 PM, Pavel Tatashin wrote:
> In every hypervisor except for xen pv time ops are initialized in
> init_hypervisor_platform().
>
> Xen PV domains initialize time ops in x86_init.paging.pagetable_init(),
> by calling xen_setup_shared_info() which is a poor design, as time is
> neede
On 07/11/2018 08:04 PM, Pavel Tatashin wrote:
> It is expected for sched_clock() to output data from 0, when system boots.
> Add an offset xen_sched_clock_offset (similarly how it is done in other
> hypervisors i.e. kvm_sched_clock_offset) to count sched_clock() from 0,
> when time is first initial
On 2/11/21 5:16 AM, Juergen Gross wrote:
> @@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
> bool spurious)
> }
>
> info->eoi_time = 0;
> + smp_store_release(&info->is_active, 0);
Can this be done in lateeoi_ack_dynirq()/lateeoi_mask_ack_dynirq(
being rogue on purpose.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 4/6/21 6:51 AM, Luca Fancellu wrote:
> Unmask operation must be called with interrupt disabled,
> on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
> don't disable/enable interrupts, so use raw_* implementation
> and change lock variable in struct irq_info from spinlock_t
> to raw_spinloc
On 12/08/2014 09:17 AM, Vitaly Kuznetsov wrote:
flush_op is unambiguously defined by feature_flush:
REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
0 -> 0
and thus can be removed. This is just a cleanup.
The patch was suggested
by Boris Ostrovsky.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Boris Ostrovsky
---
Changes from v1:
Future-proof feature_flush against new flags [Boris Ostrovsky].
The patch is supposed to be applied after "xen/blkfront: improve protection
against issuing unsupported REQ_FUA".
On 12/22/2014 07:39 PM, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Bef
On 12/23/2014 10:14 AM, Paolo Bonzini wrote:
On 23/12/2014 16:14, Boris Ostrovsky wrote:
+do {
+version = pvti->version;
+
+/* This is also a read barrier, so we'll read version first. */
+rdtsc_barrier();
+tsc = __native_read_tsc();
This will caus
On 01/22/2015 12:58 PM, Borislav Petkov wrote:
On Thu, Jan 22, 2015 at 05:43:15PM +, James Dingwall wrote:
This patch solves it for me on my dom0 with 3.18.3, now there is
nothing printed at all from the microcode driver which doesn't seem
surprising given where the return is.
Yap, xen does
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre"
In Dom0's the use of the TSC clocksource (whenever it is stable enough to
be used) instead of the Xen clocksource should not cause any issues, as
Dom0 VMs never live-migrated. The TSC clocksou
On 01/13/2015 11:07 AM, David Vrabel wrote:
On 13/01/15 15:42, Boris Ostrovsky wrote:
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre"
In Dom0's the use of the TSC clocksource (whenever it is stable
enough to
be used) ins
On 01/13/2015 11:17 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:07 AM, David Vrabel wrote:
On 13/01/15 15:42, Boris Ostrovsky wrote:
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre"
In Dom0's the use of the TSC clocksource
On 01/13/2015 11:33 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:17 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:07 AM, David Vrabel wrote:
On 13/01/15 15:42, Boris Ostrovsky wrote:
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre"
On 01/14/2015 04:34 PM, Imre Deak wrote:
Signed-off-by: Imre Deak
---
arch/x86/xen/time.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..23019b4 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -458,8 +458,6 @@ void x
With recent changes in p2m we now have legitimate cases when
p2m memory needs to be freed during early boot (i.e. before
slab is initialized).
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/p2m.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/p2m.c b
On 01/07/2015 10:10 AM, David Vrabel wrote:
On 07/01/15 14:08, Boris Ostrovsky wrote:
With recent changes in p2m we now have legitimate cases when
p2m memory needs to be freed during early boot (i.e. before
slab is initialized).
Signed-off-by: Boris Ostrovsky
Applied to to stable/for-linus
On 01/07/2015 11:16 AM, Imre Palik wrote:
From: "Palik, Imre"
In Dom0's the use of the TSC clocksource (whenever it is stable enough to
be used) instead of the Xen clocksource should not cause any issues, as
Dom0 VMs never live-migrated. The TSC clocksource is somewhat more
efficient than the
With recent changes in p2m we now have legitimate cases when
p2m memory needs to be freed during early boot (i.e. before
slab is initialized).
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
v2: Add __ref annotation
arch/x86/xen/p2m.c | 9 ++---
1 file changed, 6 insertions
On 12/17/2014 06:52 PM, Ben Skeggs wrote:
- Original Message -
From: "Dave Jones"
To: "Linux Kernel"
Cc: bske...@redhat.com
Sent: Thursday, 18 December, 2014 6:43:22 AM
Subject: nouveau oops in pramin_fini
Started seeing this during boot on one machine:
Hey Dave,
I've got a fix for
On 01/27/2015 05:12 PM, Borislav Petkov wrote:
Hey Boris,
On Thu, Jan 22, 2015 at 04:30:02PM +0100, Borislav Petkov wrote:
On Thu, Jan 22, 2015 at 09:53:04AM -0500, Boris Ostrovsky wrote:
Alternatively, we could return an error (-EINVAL?) from
microcode_init() when either of these two
then never be loaded.
Signed-off-by: Boris Ostrovsky
Reported-by: James Digwall
Cc: sta...@vger.kernel.org # 3.18
---
arch/x86/kernel/cpu/microcode/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode
On 03/19/2015 10:31 AM, Juergen Gross wrote:
Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear
virtual mapped sparse p2m list") introduced a regression regarding to
memory hotplug for a pv-domain: as the virtual space for the p2m list
is allocated for the to be expected memo
On 03/20/2015 08:55 AM, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
regions above the end of RAM as 1:1") introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be "invalid" instead of "id
On 04/06/2015 01:44 PM, Andrew Cooper wrote:
On 06/04/2015 16:29, Andy Lutomirski wrote:
On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
wrote:
On Fri, Apr 03, 2015 at 03:52:30PM -0700, Andy Lutomirski wrote:
[cc: Boris and Konrad. Whoops]
On Fri, Apr 3, 2015 at 3:51 PM, Andy Lutomir
On 04/06/2015 04:03 PM, Andy Lutomirski wrote:
On Mon, Apr 6, 2015 at 11:30 AM, Boris Ostrovsky
wrote:
On 04/06/2015 01:44 PM, Andrew Cooper wrote:
On 06/04/2015 16:29, Andy Lutomirski wrote:
On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
wrote:
On Fri, Apr 03, 2015 at 03:52:30PM
()
to x86_32") to 32-bit Xen PV guests.
Signed-off-by: Boris Ostrovsky
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/smpboot.c | 39 +++
arch/x86/xen/smp.c | 14 +-
3 files changed, 25 insertions(+), 29 deletions(-)
diff --
On 03/31/2015 11:55 AM, Ingo Molnar wrote:
* Boris Ostrovsky wrote:
Some of x86 bare-metal and Xen CPU initialization code is common between the two
and therefore can be factored out to avoid code duplication.
As a side effect, doing so will also extend the fix provided by commit
()
to x86_32") to 32-bit Xen PV guests.
Signed-off-by: Boris Ostrovsky
---
v2: Rebased on top of tip:master
arch/x86/include/asm/smp.h |1 +
arch/x86/kernel/smpboot.c | 37 ++---
arch/x86/xen/smp.c | 13 +
3 files changed, 24
On 04/24/2015 05:30 AM, Ouyang Zhaowei (Charles) wrote:
If a PVOPS VM has multi-cpu the vcpu_info of cpu0 is the member of the
structure HYPERVISOR_shared_info,
and the others is not, but after 'xl save -c/restore' the vcpu_info will be
reinitialized,
the vcpu_info of all the vcpus will be con
On 04/27/2015 06:33 AM, David Vrabel wrote:
On 08/04/15 19:53, Boris Ostrovsky wrote:
Commit 77e32c89a711 ("clockevents: Manage device's state separately for
the core") decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it
After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/xenbus/xenbus_probe.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/xen/xenbus
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
---
drivers/tty/hvc/hvc_xen.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Signed-off-by: Boris Ostrovsky
Tested-by: Annie Li
---
drivers/xen/events/events_base.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Fixes for issues that we discovered during live migration when source and
target systems have different event channel assignments for guests.
Boris Ostrovsky (4):
xen/events: Clear cpu_evtchn_mask before resuming
xen/xenbus: Update xenbus event channel on resume
xen/console: Update console
have bits for these two cleared
we won't be able to take the interrupt.
Setting IRQ_MOVE_PCNTXT flag for the two irqs avoids this problem by
allowing to set affinity immediately, which is safe for event-channel-based
interrupts.
Signed-off-by: Boris Ostrovsky
Reported-by: Annie Li
Test
are left in ONESHOT state. As result, during resume
the clockevents state machine will assume that device is already where it
should be and doesn't need to be updated.
To avoid this problem we should suspend ticks on all VCPUs during
suspend.
Signed-off-by: Boris Ostrovsky
---
Note that
On 04/28/2015 12:28 PM, David Vrabel wrote:
On 28/04/15 16:52, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
On 04/28/2015 08:30 AM, Ouyang Zhaowei (Charles) wrote:
On 2015.4.26 7:31, Boris Ostrovsky wrote:
On 04/24/2015 05:30 AM, Ouyang Zhaowei (Charles) wrote:
If a PVOPS VM has multi-cpu the vcpu_info of cpu0 is the member of the
structure HYPERVISOR_shared_info,
and the others is not, but after
e suspend) are left in ONESHOT state. As result, during
resume the clockevents state machine will assume that device is already
where it should be and doesn't need to be updated.
To avoid this problem we should suspend ticks on all VCPUs during
suspend.
Signed-off-by: Boris Ostrovsky
---
v2
e suspend) are left in ONESHOT state. As result, during
resume the clockevents state machine will assume that device is already
where it should be and doesn't need to be updated.
To avoid this problem we should suspend ticks on all VCPUs during
suspend.
Signed-off-by: Boris Ostrovsky
--
On 04/29/2015 12:32 PM, David Vrabel wrote:
On 28/04/15 19:29, Boris Ostrovsky wrote:
On 04/28/2015 12:28 PM, David Vrabel wrote:
On 28/04/15 16:52, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level
On 04/29/2015 01:59 PM, David Vrabel wrote:
On 29/04/15 17:54, Boris Ostrovsky wrote:
On 04/29/2015 12:32 PM, David Vrabel wrote:
On 28/04/15 19:29, Boris Ostrovsky wrote:
On 04/28/2015 12:28 PM, David Vrabel wrote:
From the commit log the evtchn_2l_resume() fucntion that's added
s
er to install resume notifier
Boris Ostrovsky (4):
xen/events: Clear cpu_evtchn_mask before resuming
xen/xenbus: Update xenbus event channel on resume
xen/console: Update console event channel on resume
xen/events: Set irq_info->evtchn before binding the channel to CPU in
__star
After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Use xenstore_domain_type to determine whether to install resume notifier
drivers/xen/xenbus/xenbus_probe.c | 29
there as well.
(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)
Signed-off-by: Boris Ostrovsky
Reported-by: Annie Li
---
Changes in v2:
* Don't use IRQ_MOVE_PCNTXT, bind channels to VCPUs
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
Reviewed-by: David Vrabel
---
drivers/tty/hvc/hvc_xen.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/hvc
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Signed-off-by: Boris Ostrovsky
Reviewed-by: David Vrabel
Tested-by: Annie Li
---
drivers/xen/events/events_base.c |2 +-
1 files changed
ture is no longer
HVM-specific we should do some renaming).
Signed-off-by: Boris Ostrovsky
Reported-by: Sander Eikelenboom
---
arch/x86/include/asm/hypervisor.h | 2 +-
arch/x86/kernel/cpu/hypervisor.c | 4 ++--
arch/x86/xen/enlighten.c | 27 +--
3 files c
On 04/30/2015 03:17 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:08 PM, Boris Ostrovsky
wrote:
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when
On 04/30/2015 03:35 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:30 PM, Boris Ostrovsky
wrote:
On 04/30/2015 03:17 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:08 PM, Boris Ostrovsky
wrote:
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attr
On 05/26/2015 08:07 PM, Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 10:32:03 AM Boris Ostrovsky wrote:
On 05/25/2015 10:17 PM, Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:
On
On 06/11/2015 10:07 AM, Ingo Molnar wrote:
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index fb0a9dd1d6e4..e0bf90470d70 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -391,6 +391,63 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
return NULL;
}
+/*
+ * Init
On 06/12/2015 04:53 PM, Oleg Nesterov wrote:
On 06/12, Oleg Nesterov wrote:
On 06/12, Ingo Molnar wrote:
* Linus Torvalds wrote:
So I think the only issue is that ->mm can become NULL when the thread group
leader dies - a non-NULL mm should always be shared among all threads.
Indeed, we
On 06/16/2015 10:15 AM, David Vrabel wrote:
On 15/06/15 21:35, Ingo Molnar wrote:
* David Vrabel wrote:
On 15/06/15 10:05, Ian Campbell wrote:
On Sat, 2015-06-13 at 11:49 +0200, Ingo Molnar wrote:
xen_mm_pin_all()/unpin_all() are used to implement full guest instance
suspend/restore. It's a
improve readability.
Patch was compile tested with x86_64_defconfig +
CONFIG_HYPERVISOR_GUEST=y,CONFIG_PARAVIRT=y,CONFIG_XEN=y:
Patch is against 4.1-rc5 (localversion-next is -next-20150529)
Signed-off-by: Nicholas Mc Guire
Reviewed-by: Boris Ostrovsky < boris.ostrov...@oracle.com>
---
ar
On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
>>>> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wr
On 05/22/2018 12:10 PM, Jan Beulich wrote:
>>>> On 22.05.18 at 17:15, wrote:
>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>>> On 22.05.18 at 15:45, wrote:
>>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>&g
t; On 22.05.18 at 15:45, wrote:
>>>>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>>>>>
>> wrote:
>>>>>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>>>>>>> /* 64-bit entry point. */
>>>
On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>>>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wr
On 05/22/2018 02:27 PM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
>>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
>>>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wr
Fix stack canary handling (in the first patch) and re-index PVH GDT to
make it explicit that the GDT PVH-specific
v5:
- Load canary's physical address and clear %edx for 64-bit mode
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
xen/PVH: Make GDT selectors PVH-spe
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
R
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
arch/x86/xen/xen-pvh.S | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86
On 05/23/2018 11:41 AM, Jan Beulich wrote:
On 23.05.18 at 16:30, wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>> /* 64-bit entry point. */
>> .code64
>> 1:
>> +/* Set base address in stack canary descriptor. */
>> +mov $MSR_GS_BASE,%ecx
>> +mov $_pa(canary), %rax
gt; Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
>> Reported-by: Hooman Mirhadi
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: Amit Shah
>> CC: sta...@vger.kernel.org
>
201 - 300 of 1678 matches
Mail list logo
