On 10/17/2017 04:50 PM, Josh Poimboeuf wrote:
> On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote:
>> On 10/17/2017 04:17 PM, Josh Poimboeuf wrote:
>>> On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote:
>>>> On 10/17/2017 10:36 AM, Josh P
On 10/17/2017 04:17 PM, Josh Poimboeuf wrote:
> On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote:
>> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote:
>>> Maybe we can add a new field to the alternatives entry struct which
>>> specifies the offset
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a waitqueue to allow only one outstanding accept command at
> any given time and to implement polling on the passive socket. Introduce
> a flags field to keep track of in-flight accept and poll commands.
>
> Send PVCALLS_ACCEPT to the b
> + if (!pvcalls_front_dev) {
> + pvcalls_exit();
> + return -ENOTCONN;
The connect patch returns -ENETUNREACH here. Is there a deliberate
distinction between these cases?
Other than that
Reviewed-by: Boris Ostrovsky
.
> This way, we can easily get the struct sock_mapping from the struct
> socket.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
with one question:
> + /*
> + * PVCalls only supports domain AF_INET,
> + * type SOCK_STREAM and protoc
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to all
On 10/17/2017 10:36 AM, Josh Poimboeuf wrote:
>
> Maybe we can add a new field to the alternatives entry struct which
> specifies the offset to the CALL instruction, so apply_alternatives()
> can find it.
We'd also have to assume that the restore part of an alternative entry
is the same size as th
On 10/17/2017 09:10 AM, Brian Gerst wrote:
> On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky
> wrote:
>>
>> Replacing the macro with
>>
>> #define PV_INDIRECT(addr) *addr // well, it's not so much
>> indirect anymore
>>
>> makes thing
On 10/17/2017 01:24 AM, Josh Poimboeuf wrote:
> On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
>> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
>>> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
>>>> On 12/10/17 20:11, Boris Ostrovsky wrote:
>&
driver, the network
>> will become unreachable immediately, the guest can no longer be pinged.
>>
>> xen_net{front|back} should not allow the user to set this value which causes
>> network problems.
>>
>> Reported-by: Chen Shi
>> Signed-off-by: Mohammed Gamal
On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
>> On 12/10/17 20:11, Boris Ostrovsky wrote:
>>> There is also another problem:
>>>
>>> [1.312425] general protection fault: [#1] SMP
>>> [1.3129
| 10 +-
> 9 files changed, 37 insertions(+), 31 deletions(-)
Xen bits:
Reviewed-by: Boris Ostrovsky
with a couple of nits:
> @@ -136,11 +136,17 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
> *wall_clock,
> rmb(); /* fetch tim
On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> On 12/10/17 20:11, Boris Ostrovsky wrote:
>> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>>>> #ifdef CONFIG_PARAVIRT
>>>>> +/*
On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>> #ifdef CONFIG_PARAVIRT
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only appl
> The trace events xen_mmu_set_pte_atomic, xen_mmu_pte_clear, and
> xen_mmu_pmd_clear are not used when CONFIG_X86_PAE is not defined.
>
> Signed-off-by: Steven Rostedt (VMware)
Reviewed-by: Boris Ostrovsky
On 10/08/2017 10:58 PM, Zhenzhong Duan wrote:
> As xen_cpuhp_setup is called by PV and PVHVM, the name of "x86/xen/hvm_guest"
> is confusing.
>
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Applied to for-linus-4.14c.
-boris
f-by: Jan Beulich
> Reviewed-by: Juergen Gross
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Sasha Levin
This patch will cause a warning to be printed. Please pull commit
4e93b64 ("xen: don't print error message in case of missing Xenstore
entry") as well.
Thanks.
-
On 10/06/2017 02:38 PM, Stefano Stabellini wrote:
> On Thu, 21 Sep 2017, Boris Ostrovsky wrote:
>>> +
>>> +static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
>>> +{
>>> + *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(&
On 10/06/2017 04:29 PM, Stefano Stabellini wrote:
> On Fri, 6 Oct 2017, Boris Ostrovsky wrote:
>> On 10/06/2017 01:51 PM, Stefano Stabellini wrote:
>>> On Wed, 20 Sep 2017, Boris Ostrovsky wrote:
>>>>> +
>>>>> +struct pvcalls_bedata {
>>>>
On 10/06/2017 01:51 PM, Stefano Stabellini wrote:
> On Wed, 20 Sep 2017, Boris Ostrovsky wrote:
>>> +
>>> +struct pvcalls_bedata {
>>> + struct xen_pvcalls_front_ring ring;
>>> + grant_ref_t ref;
>>> + int irq;
>>> +
>>&
On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>> #ifdef CONFIG_PARAVIRT
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only appl
> #ifdef CONFIG_PARAVIRT
> +/*
> + * Paravirt alternatives are applied much earlier than normal alternatives.
> + * They are only applied when running on a hypervisor. They replace some
> + * native instructions with calls to pv ops.
> + */
> +void __init apply_pv_alternatives(void)
> +{
> +
On 10/02/2017 05:37 PM, HW42 wrote:
> Juergen Gross:
>> When setting up the Xenstore watch for the memory target size the new
>> watch will fire at once. Don't try to reach the configured target size
>> by onlining new memory in this case, as the current memory size will
>> be smaller in almost all
hypercall for
registering the secondary vcpu_time_info struct.
Signed-off-by: Joao Martins
Reviewed-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
> +
> +static void xen_setup_vsyscall_time_info(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + struct pvclock_vsyscall_time_info *ti;
> + int ret;
In the previous version you'd return immediately if
PVCLOCK_TSC_STABLE_BIT was not set. Don't you still need to check this?
y: Joao Martins
Reviewed-by: Boris Ostrovsky
SYM_CODE_END, appropriatelly.
>
> Signed-off-by: Jiri Slaby
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Pavel Machek
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
&g
ere
> the last users.
>
> Signed-off-by: Jiri Slaby
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: x...@kernel.org
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> C
y
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: xen-de...@lists.xenproject.org
For Xen bits:
Reviewed-by: Boris Ostrovsky
SYM_CODE_END, appropriatelly.
>
> Signed-off-by: Jiri Slaby
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
For Xen bits:
Reviewed-by: Boris Ostrovsky
L DEFAULT6 early_stack
> 0128 0 OBJECT LOCAL DEFAULT6 early_stack
>
> Signed-off-by: Jiri Slaby
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: x
On 09/27/2017 04:57 PM, Joao Martins wrote:
> On 09/27/2017 09:22 PM, Boris Ostrovsky wrote:
>> On 09/27/2017 11:26 AM, Joao Martins wrote:
>>> On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>>>>> +static void xen_setup_vsyscall_time_i
On 09/27/2017 11:26 AM, Joao Martins wrote:
> On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>>> +static void xen_setup_vsyscall_time_info(void)
>>> +{
>>> + struct vcpu_register_time_memory_area t;
>>> + struct pvclock_vsyscall_time_info *ti;
>
On 09/27/2017 05:43 AM, Juergen Gross wrote:
> On 27/09/17 11:41, Zhenzhong Duan wrote:
>> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial
>> mapping overlaps with kernel module virtual space. When mapping in this space
>> is cleared by xen_cleanhighmap(), in certain case
On 09/27/2017 10:56 AM, Juergen Gross wrote:
> On 27/09/17 16:48, Boris Ostrovsky wrote:
>> On 09/27/2017 10:33 AM, Juergen Gross wrote:
>>> On 27/09/17 15:38, Boris Ostrovsky wrote:
>>>> On 09/27/2017 05:43 AM, Juergen Gross wrote:
>>>>> On 27/09/17 11
On 09/27/2017 10:33 AM, Juergen Gross wrote:
> On 27/09/17 15:38, Boris Ostrovsky wrote:
>> On 09/27/2017 05:43 AM, Juergen Gross wrote:
>>> On 27/09/17 11:41, Zhenzhong Duan wrote:
>>>> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial
>
> +static void xen_setup_vsyscall_time_info(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + struct pvclock_vsyscall_time_info *ti;
> + struct pvclock_vcpu_time_info *pvti;
> + int ret;
> +
> + pvti = &__this_cpu_read(xen_vcpu)->time;
> +
> + /*
> + * We che
On 09/27/2017 05:43 AM, Juergen Gross wrote:
> On 27/09/17 11:41, Zhenzhong Duan wrote:
>> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial
>> mapping overlaps with kernel module virtual space. When mapping in this space
>> is cleared by xen_cleanhighmap(), in certain case
>> + */
>> +map->active.ring->in_error = -EBADF;
>> +wake_up_interruptible(&map->active.inflight_conn_req);
>> +
>> +/*
>> + * Wait until there are no more waiters on the mutexes.
>> + * We know that no new waiters can be adde
>
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map)
I just noticed: pvcalls_front_free_map() is referenced by patches 2 and 8.
> +{
> + int i;
> +
> + unbind_from_irqhandler(map->active.irq, map);
> +
> +
>
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> +
>
> +static bool pvcalls_front_read_todo(struct sock_mapping *map)
> +{
> + struct pvcalls_data_intf *intf = map->active.ring;
> + RING_IDX cons, prod;
> + int32_t error;
> +
> + cons = intf->in_cons;
> + prod = intf->in_prod;
> + error = intf->in_error;
> + return (e
> +static bool pvcalls_front_write_todo(struct sock_mapping *map)
> +{
> + struct pvcalls_data_intf *intf = map->active.ring;
> + RING_IDX cons, prod, size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> + int32_t error;
> +
> + cons = intf->out_cons;
> + prod = intf->out_prod;
> +
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int
flags)
+{
+ struct pvcalls_bedata *bedata;
+ struct sock_mapping *map;
+ struct sock_mapping *map2 = NULL;
+ struct xen_pvcalls_request *req;
+ int notify, req_id, ret, evtchn, nonblock;
+
+
On 09/15/2017 07:00 PM, Stefano Stabellini wrote:
Send PVCALLS_BIND to the backend. Introduce a new structure, part of
struct sock_mapping, to store information specific to passive sockets.
Introduce a status field to keep track of the status of the passive
socket.
Signed-off-by: Stefano Stab
On 09/21/2017 12:16 PM, Andrew Cooper wrote:
On 21/09/17 17:00, Boris Ostrovsky wrote:
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/page.h | 11 ++-
arch/x86/xen/mmu_pv.c | 4 ++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a
backend on the active socket (recvmsg command).
Two mutexes (one of reads and one for writes) will be used to protect
the active socket in and out rings from concurrent accesses.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
with a couple of nits below and comments from previous
+
+static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
+{
+ *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(&bedata->ring) - 1);
+ if (RING_FULL(&bedata->ring) ||
+ READ_ONCE(bedata->rsp[*req_id].req_id) != PVCALLS_INVALID_ID)
+ return
On 09/21/2017 10:41 AM, Juergen Gross wrote:
On 21/09/17 16:14, Boris Ostrovsky wrote:
On 09/21/2017 04:01 AM, Juergen Gross wrote:
Physical addresses on processors supporting 5 level paging can be up to
52 bits wide. For a Xen pv guest running on such a machine those
physical addresses
On 09/21/2017 04:01 AM, Juergen Gross wrote:
Physical addresses on processors supporting 5 level paging can be up to
52 bits wide. For a Xen pv guest running on such a machine those
physical addresses have to be supported in order to be able to use any
memory on the machine even if the guest it
; for a guest. Store the active frontend device to a static pointer.
>
> Introduce a stub functions for the event handler.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Reviewed-by: Boris Ostrovsky
>
> static int pvcalls_front_remove(struct xenbus_device *dev)
> {
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL, *n;
> +
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> + dev_set_drvdata(&dev->dev, NULL);
> + pvcalls_front_dev = NULL;
One
> +
> +struct pvcalls_bedata {
> + struct xen_pvcalls_front_ring ring;
> + grant_ref_t ref;
> + int irq;
> +
> + struct list_head socket_mappings;
> + struct list_head socketpass_mappings;
> + spinlock_t socket_lock;
> +
> + wait_queue_head_t inflight_req;
> + struc
On 09/14/2017 08:38 AM, Juergen Gross wrote:
> xenbus_client.c contains some functions specific for pv guests.
> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
> they are not needed (e.g. on ARM).
>
> Signed-off-by: Juergen Gross
Applied to for-linus-14b.
-boris
On 09/18/2017 02:08 PM, Stefano Stabellini wrote:
> On Fri, 15 Sep 2017, Greg KH wrote:
>> On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote:
>>> Hi all,
>>>
>>> We are getting reports from Xen on ARM users about DMA issues. The
>>> problem is that the commit below
>>> (7e91c7df29b
On 09/15/2017 03:29 PM, Arnd Bergmann wrote:
> gcc-4.6 causes a harmless link-time warning:
>
> WARNING: vmlinux.o(.text.unlikely+0x48e): Section mismatch in reference from
> the function xen_find_pt_base() to the function .init.text:m2p()
> The function xen_find_pt_base() references
> the functio
ts).
Oh, OK, I didn't notice that.
Reviewed-by: Boris Ostrovsky
On 09/14/2017 08:38 AM, Juergen Gross wrote:
> xenbus_client.c contains some functions specific for pv guests.
> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
> they are not needed (e.g. on ARM).
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/xenbus/xenbus_client.c | 1
On 09/13/2017 10:45 AM, Juergen Gross wrote:
> On 13/09/17 15:50, Boris Ostrovsky wrote:
>> On 09/13/2017 09:38 AM, Juergen Gross wrote:
>>> On 13/09/17 15:22, Boris Ostrovsky wrote:
>>>> On 09/12/2017 02:18 PM, Juergen Gross wrote:
>>>>> On 12/09/17
On 09/13/2017 09:38 AM, Juergen Gross wrote:
> On 13/09/17 15:22, Boris Ostrovsky wrote:
>> On 09/12/2017 02:18 PM, Juergen Gross wrote:
>>> On 12/09/17 18:21, Boris Ostrovsky wrote:
>>>> On 09/12/2017 12:09 PM, Juergen Gross wrote:
>>>>> On 12/09/17
On 09/12/2017 02:18 PM, Juergen Gross wrote:
> On 12/09/17 18:21, Boris Ostrovsky wrote:
>> On 09/12/2017 12:09 PM, Juergen Gross wrote:
>>> On 12/09/17 18:05, Boris Ostrovsky wrote:
>>>> On 09/12/2017 11:50 AM, Juergen Gross wrote:
>>>>> On 12/09/17
On 09/12/2017 06:17 PM, Stefano Stabellini wrote:
> On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
>>>>> +
>>>>> +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
>>>>> +poll_table *wait)
>>>&g
On 09/12/2017 12:09 PM, Juergen Gross wrote:
> On 12/09/17 18:05, Boris Ostrovsky wrote:
>> On 09/12/2017 11:50 AM, Juergen Gross wrote:
>>> On 12/09/17 17:44, Boris Ostrovsky wrote:
>>>> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>>>>> As ther
On 09/08/2017 10:48 AM, Juergen Gross wrote:
> Based on the maximum page number of the host select either grant v1 or
> grant v2.
>
> For testing purposes add a way to specify the grant interface version
> via a boot parameter.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 09/12/2017 11:50 AM, Juergen Gross wrote:
> On 12/09/17 17:44, Boris Ostrovsky wrote:
>> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>>> As there is currently no user for sub-page grants or transient grants
>>> remove that functionality. This at once makes it possib
ible suggestion --- define gnttab_sframes() inline and get rid
of RPP/SPP.
But either way:
Reviewed-by: Boris Ostrovsky
-boris
On 09/08/2017 10:48 AM, Juergen Gross wrote:
> As there is currently no user for sub-page grants or transient grants
> remove that functionality. This at once makes it possible to switch
> from grant v2 to grant v1 without restrictions, as there is no loss of
> functionality other than the limited
> +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> +unsigned long max_nr_gframes,
> +grant_status_t **__shared)
> +{
> + grant_status_t *shared = *__shared;
> + unsigned long addr;
> + unsigned long i;
> +
> +
>>> +
>>> +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
>>> + poll_table *wait)
>>> +{
>>> + struct pvcalls_bedata *bedata;
>>> + struct sock_mapping *map;
>>> +
>>> + if (!pvcalls_front_dev)
>>> + return POLLNVAL;
>>> + bedata
aptop executing start_kernel() by a guest
takes ~10 times more than when KVM's ops are used.
Since early_xdbc_setup_hardware() relies on calibration having been
performed move it too.
Signed-off-by: Boris Ostrovsky
---
v2:
* Move xdbc initialization down as well.
Alternatively, we could sta
aptop executing start_kernel() by a guest
takes ~10 times more than when KVM's ops are used.
Signed-off-by: Boris Ostrovsky
---
Alternatively, we could start calling simple_udelay_calibration() only
on bare metal: My understanding is that the only reason it exists is to
help with USB3 earlyprink drive
On 09/06/2017 02:19 PM, Borislav Petkov wrote:
> On Wed, Sep 06, 2017 at 01:06:50PM -0500, Brijesh Singh wrote:
>> I did the following quick run with your patch and everything seems to be
>> working okay
>>
>> 64-bit build:
>> ---
>> 1) Baremetal SME *enabled* - System boots fine
>> a) 32-bit
On 09/06/2017 09:57 AM, Thomas Gleixner wrote:
> On Wed, 6 Sep 2017, Boris Ostrovsky wrote:
>> On 09/06/2017 05:26 AM, Borislav Petkov wrote:
>>> On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote:
>>>> It appears there is a regression for 32-
On 09/06/2017 05:26 AM, Borislav Petkov wrote:
> On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote:
>> It appears there is a regression for 32-bit kernels due to SME changes.
>>
>> I bisected my particular problem
> It being? Doesn't boot, splats?
It appears there is a regression for 32-bit kernels due to SME changes.
I bisected my particular problem (Xen PV guest) to
21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad()
errors on baremetal. This seems to be caused by sme_me_mask being an
unsigned long as opposed to ph
On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Juergen Gross wrote:
>>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
>>> mindlessly. Patch below.
>>>
>>> Juergen, can you please check the result?
>> You missed the updates to arch/x86/xen/xen-asm_64.
t;
> Signed-off-by: Jérôme Glisse
> Cc: Konrad Rzeszutek Wilk
> Cc: Roger Pau Monné
> Cc: Boris Ostrovsky
> Cc: xen-de...@lists.xenproject.org
> Cc: Kirill A. Shutemov
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Andrea Arcangeli
> ---
> drivers/xen/g
On 08/26/2017 09:05 AM, Thomas Gleixner wrote:
What occured to me right now, is that the patch removes:
load_idt(&idt_descr);
from the original function without adding it to the new one.
Right, that's exactly what was broken for Xen.
So that needs
to be fixed, but not in the XEN
On 08/25/2017 05:47 PM, Thomas Gleixner wrote:
>
> -/* Set of traps needed for early debugging. */
> -void __init early_trap_init(void)
> -{
> - /*
> - * Don't use IST to set DEBUG_STACK as it doesn't work until TSS
> - * is ready in cpu_init() <-- trap_init(). Before trap_init(),
>
ixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
Reviewed-by: Boris Ostrovsky
>
> Index: b/arch/x86/xen/enlighten_pv.c
> ===
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -494,7 +494,7 @@ static void __init xen_load_gdt_boot(con
> static inline bool desc_equal(const struct desc
event this from happening by adding XENFEAT_auto_translated_physmap
check there.
Signed-off-by: Boris Ostrovsky
Fixes: aba831a69632 ("xen: remove tests for pvh mode in pure pv paths")
---
drivers/xen/balloon.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/d
On 08/22/2017 12:15 PM, Julien Grall wrote:
> Hi,
>
> Gentle ping. This patch was reviewed but not queued. Are we waiting
> for other reviewed?
Applied to for-linus-4.14.
-boris
Adding maintainer (Dmitry).
-boris
On 08/21/2017 11:41 AM, Liang Yan wrote:
> Long pressed key could not show right in XEN vncviewer after tigervnc
> client changed the way how to send repeat keys, from "Down Up Down Up
> ..." to "Down Down Dow." By enable EV_REP bit here, XEN keyboard
> device w
On 08/21/2017 10:46 AM, Juergen Gross wrote:
> On 21/08/17 16:31, Boris Ostrovsky wrote:
>> On 08/21/2017 09:33 AM, Juergen Gross wrote:
>>> On 06/08/17 18:44, Mikko Rapeli wrote:
>>>> Both are needed to compile in userspace. Fixes these
>>>> userspace co
> ^
>> xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
>> domid_t domid;
>> ^
>>
>> Signed-off-by: Mikko Rapeli
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: xen-de...@lists.xenproject.org
>> ---
>> include/ua
On 08/16/2017 01:31 PM, Juergen Gross wrote:
> Xen's paravirt patch function xen_patch() does some special casing for
> irq_ops functions to apply relocations when those functions can be
> patched inline instead of calls.
>
> Unfortunately none of the special case function replacements is small
> e
set).
>
> xen_evtchn_fifo_init() will always be called before SMP is initialized,
> so {get,put}_cpu() could be replaced by a simple smp_processor_id().
On x86 this will be called out of init_IRQ(), which is already preceded
by preempt_disable().
Reviewed-by: Boris Ostrovsky
On 08/17/2017 05:03 AM, Juergen Gross wrote:
> A kernel configured with XEN_PV but without KVM_GUEST will fail to
> build since the patch removing the adjust_exception_frame paravirt
> op.
>
> Fix this failure.
>
> Reported-by: Sander Eikelenboom
> Signed-off-by: Juergen Gross
> ---
> arch/x86/x
On 08/16/2017 12:42 PM, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
>> Peter Zijlstra writes:
>>
>>> On Fri, Aug 11, 2017 at 09:16:29AM -0700, Linus Torvalds wrote:
On Fri, Aug 11, 2017 at 2:03 AM, Peter Zijlstra
wrote:
> I'm sure we talked about using HAVE_RCU_TABLE_FREE
On 07/21/2017 03:26 PM, Stefano Stabellini wrote:
> On Fri, 21 Jul 2017, Arnd Bergmann wrote:
>> __WARN() is an internal helper that is only available on
>> some architectures, but causes a build error e.g. on ARM64
>> in some configurations:
>>
>> drivers/xen/pvcalls-back.c: In function 'set_backe
ps.h| 1 -
> 12 files changed, 140 insertions(+), 78 deletions(-)
Reviewed-by: Boris Ostrovsky
Applied to for-linus-4.14.
-boris
On 08/04/2017 07:36 AM, Juergen Gross wrote:
> Remove stuff no longer needed.
>
> Juergen Gross (3):
> xen: remove tests for pvh mode in pure pv paths
> xen: remove unused function xen_set_domain_pte()
> xen: remove not used trace functions
>
> arch/x86/include/asm/xen/page.h | 5 -
> a
On 08/02/2017 06:36 PM, Boris Ostrovsky wrote:
> On 08/02/2017 01:46 PM, Arvind Yadav wrote:
>> pci_device_id are not supposed to change at runtime. All functions
>> working with pci_device_id provided by work with
>> const pci_device_id. So mark the non-const structs as co
On 07/27/2017 11:44 AM, Juergen Gross wrote:
> On 27/07/17 17:37, Boris Ostrovsky wrote:
>> On 07/27/2017 11:11 AM, Juergen Gross wrote:
>>> The macros for testing domain types are more complicated then they
>>> need to. Simplify them.
>>>
>>> Signed-of
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> socket.
>
> For passive sockets, check whether we have already pre-allocated an
> active socket for the pur
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> For active sockets, check the indexes and use the inflight_conn_req
> waitqueue to wait.
>
> For passive sockets if an accept is outstanding
> (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking
> at bedata->rsp[req_id]. If so
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring a
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.
If not enough room is available on the ring, rather than returning
immediately or
+
+ret = bedata->rsp[req_id].ret;
You can just return bedata->rsp[req_id].ret;
Or maybe not. The slot may get reused by the time you get to the end.
-boris
-boris
+/* read ret, then set this rsp slot to be reused */
+smp_mb();
+WRITE_ONCE(bedata->rsp[req_id].req_id, PVC
501 - 600 of 1644 matches
Mail list logo
