On 11/22/2017 11:54 AM, Christian König wrote:
> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
>> On 11/22/2017 05:09 AM, Christian König wrote:
>>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
>>>> On 11/21/2017 08:34 AM, Christian König wrote:
>>>&g
On 11/22/2017 05:09 AM, Christian König wrote:
> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
>> On 11/21/2017 08:34 AM, Christian König wrote:
>>> Hi Boris,
>>>
>>> attached are two patches.
>>>
>>> The first one is a trivial fix for th
On 11/22/2017 09:40 AM, Juergen Gross wrote:
> On 22/11/17 15:05, Jan Beulich wrote:
>> Jürgen, Boris,
>>
>> am I trying something that's not allowed, but selectable via Kconfig?
>> On system with multiple IO-APICs (I assume that's what triggers the
>> problem) I get
>>
>> Kernel panic - not syncin
On 11/20/2017 11:43 AM, Jan Beulich wrote:
On 20.11.17 at 17:28, wrote:
>> On 11/20/2017 11:26 AM, Jan Beulich wrote:
>> On 20.11.17 at 17:14, wrote:
What could cause grub2 to fail to find space for the pointer in the
first page? Will we ever have anything in EBDA (which is one
On 11/20/2017 11:26 AM, Jan Beulich wrote:
On 20.11.17 at 17:14, wrote:
>> What could cause grub2 to fail to find space for the pointer in the
>> first page? Will we ever have anything in EBDA (which is one of the
>> possible RSDP locations)?
> Well, the EBDA (see the B in its name) is again
On 11/20/2017 10:27 AM, Juergen Gross wrote:
> On 20/11/17 15:25, Boris Ostrovsky wrote:
>> On 11/20/2017 09:14 AM, Juergen Gross wrote:
>>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>>>>
On 11/20/2017 09:36 AM, Andrew Cooper wrote:
> On 20/11/17 14:25, Boris Ostrovsky wrote:
>> On 11/20/2017 09:14 AM, Juergen Gross wrote:
>>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>>>>
On 11/20/2017 09:14 AM, Juergen Gross wrote:
> On 20/11/17 14:56, Boris Ostrovsky wrote:
>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>> On 20.11.17 at 12:20, wrote:
>>>> Which restriction? I'm loading the RSDP table to its architectural
>>&
On 11/20/2017 06:50 AM, Jan Beulich wrote:
On 20.11.17 at 12:20, wrote:
>> Which restriction? I'm loading the RSDP table to its architectural
>> correct addres if possible, otherwise it will be loaded to the same
>> address as without my patch. So I'm not adding a restriction, but
>> removing
On 11/20/2017 06:20 AM, Juergen Gross wrote:
> On 20/11/17 11:57, Andrew Cooper wrote:
>> On 20/11/17 10:43, Juergen Gross wrote:
>>> On 20/11/17 11:21, Andrew Cooper wrote:
On 20/11/17 10:04, Juergen Gross wrote:
> On 20/11/17 10:58, Andrew Cooper wrote:
>> On 20/11/2017 09:55, Juerge
On 11/19/2017 10:22 AM, osstest service owner wrote:
flight 116316 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 7 x
/vmcb.c| 12
> xen/include/asm-x86/hvm/svm/svm.h | 2 ++
> xen/include/asm-x86/hvm/svm/vmcb.h | 6 --
> 5 files changed, 25 insertions(+), 3 deletions(-)
>
Reviewed-by: Boris Ostrovsky
(with or without 'else' style changes in the second pat
On 11/15/2017 04:50 PM, Stefano Stabellini wrote:
>
> Sorry, code style issue: one missing space in the comment. I'll send it
> again separately
I've already fixed this, no worries.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
On 11/15/2017 02:50 PM, Boris Ostrovsky wrote:
> On 11/15/2017 02:09 PM, Stefano Stabellini wrote:
>>
>> However, I should note that this is a pretty big hammer we are using:
>> the refcount is global, while we only need to wait until it's only us
>> _on this spe
On 11/15/2017 02:09 PM, Stefano Stabellini wrote:
> On Wed, 15 Nov 2017, Juergen Gross wrote:
> while(mutex_is_locked(&map->active.in_mutex.owner) ||
> mutex_is_locked(&map->active.out_mutex.owner))
> cpu_relax();
>
> ?
I'm not convince
Since commit ba1029c9cbc5 ("modpost: detect modules without a
MODULE_LICENSE") modules without said macro will generate
WARNING: modpost: missing MODULE_LICENSE() in
While at it, also add module description and attribution.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/pvcalls-b
On 11/14/2017 04:11 AM, Juergen Gross wrote:
> On 13/11/17 19:33, Stefano Stabellini wrote:
>> On Mon, 13 Nov 2017, Juergen Gross wrote:
>>> On 11/11/17 00:57, Stefano Stabellini wrote:
On Tue, 7 Nov 2017, Juergen Gross wrote:
> On 06/11/17 23:17, Stefano Stabellini wrote:
>> mutex_try
On 11/10/2017 06:57 PM, Stefano Stabellini wrote:
On Tue, 7 Nov 2017, Juergen Gross wrote:
On 06/11/17 23:17, Stefano Stabellini wrote:
mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
take in_mutex on the first try, but you can't take out_mutex. Next times
you call mut
On 11/08/2017 12:19 PM, Joao Martins wrote:
> Hey,
>
> This is take 8 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting
> Xen
> 4.8 which is required for vdso time related calls. In order to have it on,
> you
> need to have the hypervisor clocksource be TSC e.g. with the following boo
These tables are pointed to from FADT. Adding them will
result in duplicate entries in the guest's tables.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Merge (pvh_acpi_table_allowed(sig) && pvh_acpi_table_in_xsdt(sig)) into
a single call
* Make this call return a boolean
On 11/08/2017 08:30 AM, Juergen Gross wrote:
> On 08/11/17 14:00, Colin King wrote:
>> From: Colin Ian King
>>
>> Variable pageidx is assigned a value but it is never read, hence it
>> is redundant and can be removed. Cleans up clang warning:
>>
>> drivers/xen/privcmd.c:199:2: warning: Value store
On 11/06/2017 03:46 PM, Boris Ostrovsky wrote:
> On 11/02/2017 05:19 AM, Juergen Gross wrote:
>> In order to support Linux to run as a pv guest on machines with huge
>> memory (>16TB) or as a hvm guest with more than 16TB of memory the
>> kernel has to support grant tabl
On 11/03/2017 04:51 PM, Boris Ostrovsky wrote:
> On 11/03/2017 01:04 PM, Paul Durrant wrote:
>> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
>> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
>>
>> This patch adds checks in xen_r
On 11/03/2017 06:01 AM, Juergen Gross wrote:
> On 03/11/17 10:20, Colin King wrote:
>> From: Colin Ian King
>>
>> This is a moot point, but irq is always less than zero at the label
>> out_error, so the check for irq >= 0 is redundant and can be removed.
>>
>> Detected by CoverityScan, CID#1460371
On 11/03/2017 05:01 AM, Juergen Gross wrote:
> On 03/11/17 09:42, Colin King wrote:
>> From: Colin Ian King
>>
>> The check on bedata->ref is never true because ref is an unsigned
>> integer. Fix this by assigning signed int ret to the return of the
>> call to gnttab_claim_grant_reference so the -
On 11/03/2017 04:04 AM, Juergen Gross wrote:
> On 02/11/17 19:51, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Notice that in this particular case I placed the "fall through" comment
>> on its own
On 11/03/2017 04:03 AM, Juergen Gross wrote:
> On 02/11/17 19:41, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Addresses-Coverity-ID: 146562
>> Addresses-Coverity-ID: 146563
>> Signed-off-by: Gust
On 10/31/2017 09:46 PM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_c
These tables are pointed to from FADT. Adding them will
result in duplicate entries in the guest's tables.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/dom0_build.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c
On 11/08/2017 09:17 AM, Juergen Gross wrote:
> On 08/11/17 15:10, Boris Ostrovsky wrote:
>> On 11/08/2017 08:36 AM, Juergen Gross wrote:
>>> Regarding ACPI tables: current PVH implementation in Linux kernel
>>> seems not to make use of the special information presented
On 11/08/2017 08:36 AM, Juergen Gross wrote:
>
> Regarding ACPI tables: current PVH implementation in Linux kernel
> seems not to make use of the special information presented in the boot
> information block.
It will need to do so for dom0 (and, then, for simplicity, for all PVH
guests).
-boris
On 11/08/2017 08:40 AM, Juergen Gross wrote:
> On 08/11/17 14:37, Boris Ostrovsky wrote:
>> On 11/08/2017 04:07 AM, Juergen Gross wrote:
>>> Booting a Xen PVH guest requires a special boot entry as it is
>>> mandatory to setup some Xen-specific interfaces rather early
On 11/08/2017 04:07 AM, Juergen Gross wrote:
> Booting a Xen PVH guest requires a special boot entry as it is
> mandatory to setup some Xen-specific interfaces rather early. When grub
> or OVMF are used as boot loaders, however, those will fill the boot
> parameters in zeropage and there is no long
On 11/07/2017 02:42 AM, Juergen Gross wrote:
> On 06/11/17 17:42, Boris Ostrovsky wrote:
>> On 11/06/2017 10:05 AM, Juergen Gross wrote:
>>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>>>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>>>> On 03/11/17
>
> Solve the problem by moving the two mutex_trylock calls to two separate
> loops.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Reviewed-by: Boris Ostrovsky
BTW, I assume that when recvms
ter
> - in a pv guest if the maximum possible memory address of the host is
> above 16TB (memory hotplug taken into account)
> - in a hvm guest if the maximum guest memory address is above 16TB
> (again with memory hotplug taken into account)
>
> Changes in V2:
> - patch 2: rem
On 11/06/2017 10:05 AM, Juergen Gross wrote:
> On 06/11/17 15:51, Boris Ostrovsky wrote:
>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>>>> On 03/11/17
On 11/06/2017 02:16 AM, Juergen Gross wrote:
> On 03/11/17 20:00, Boris Ostrovsky wrote:
>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>>>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>>>>> On 03/11/17
call through to the approprate
> xlate_mmu function if the feature is present. A check is also added
> to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
> should not be used in an HVM tools domain.
>
> Signed-off-by: Paul Durrant
On 11/03/2017 02:40 PM, Juergen Gross wrote:
> On 03/11/17 19:35, Boris Ostrovsky wrote:
>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>>>> So again th
On 11/03/2017 02:23 PM, Juergen Gross wrote:
> On 03/11/17 19:19, Boris Ostrovsky wrote:
>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>> So again the question: how to tell whether we are PVH or HVM in
>>> init_hypervisor_platform()? ACPi tables are scanned way later.
On 11/03/2017 02:05 PM, Juergen Gross wrote:
>
> So again the question: how to tell whether we are PVH or HVM in
> init_hypervisor_platform()? ACPi tables are scanned way later...
Can we make grub/OVMF append a boot option?
Or set setup_header.hardware_subarch to something? We already have
X86_SU
On 11/03/2017 10:59 AM, Juergen Gross wrote:
> On 03/11/17 15:36, Boris Ostrovsky wrote:
>> On 11/03/2017 10:24 AM, Juergen Gross wrote:
>>> On 03/11/17 15:07, Roger Pau Monné wrote:
>>>> On Fri, Nov 03, 2017 at 01:50:11PM +0100, Juergen Gross wrote:
>>>>
On 11/03/2017 10:24 AM, Juergen Gross wrote:
> On 03/11/17 15:07, Roger Pau Monné wrote:
>> On Fri, Nov 03, 2017 at 01:50:11PM +0100, Juergen Gross wrote:
>>> On 03/11/17 13:17, Roger Pau Monné wrote:
On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
> On 29/09/17 17:51, Roger
For any other error sync_cmos_clock() will reschedule itself
every second or so, for no good reason.
Suggested-by: Paolo Bonzini
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
On 11/02/2017 05:30 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: 01 November 2017 18:19
>> To: Juergen Gross ; Paul Durrant
>> ; x...@kernel.org; xen-
>> de...@lists.xenproject.org
On 11/01/2017 09:19 PM, Dongli Zhang wrote:
> Hi Boris,
>
> I have received from l...@intel.com that the prior version of patch hit issue
> during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by
> you would hit the same compiling issue on arm64 (there is no issue with
> x86_
On 11/01/2017 04:58 PM, Waiman Long wrote:
> +/* TODO: To be removed in a future kernel version */
> static __init int xen_parse_nopvspin(char *arg)
> {
> - xen_pvspin = false;
> + pr_warn("xen_nopvspin is deprecated, replace it with
> \"pvlock_type=queued\"!\n");
> + if (!pv_spinloc
est,
> which would overflow steal time and lead to 100% st usage in top command
> for linux 4.8-4.10. A backport of this patch would fix that issue.
>
> References:
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> Signed-off-by: Dongli
On 11/01/2017 12:28 PM, Waiman Long wrote:
> On 11/01/2017 11:51 AM, Juergen Gross wrote:
>> On 01/11/17 16:32, Waiman Long wrote:
>>> Currently, there are 3 different lock types that can be chosen for
>>> the x86 architecture:
>>>
>>> - qspinlock
>>> - pvqspinlock
>>> - unfair lock
>>>
>>> One
the callers are now switched to _mfn(domain_page_to_mfn(...)).
>
> Signed-off-by: Julien Grall
>
SVM:
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 11/01/2017 11:37 AM, Juergen Gross wrote:
>
> TBH I like V1 better, too.
>
> Boris, do you feel strong about the #ifdef part?
Having looked at what this turned into I now like V1 better too ;-)
Sorry, Paul.
-boris
___
Xen-devel mailing list
Xen-de
bug.c | 2 ++
> xen/arch/x86/hvm/svm/vmcb.c | 7 +++
> xen/include/asm-x86/hvm/svm/nestedsvm.h | 4 ++--
> xen/include/asm-x86/hvm/svm/svm.h | 2 ++
> xen/include/asm-x86/hvm/svm/vmcb.h | 7 ---
> 7 files changed, 24 insertions(+), 11 deleti
On 10/27/2017 01:49 PM, 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 gues
On 10/30/2017 06:40 PM, Stefano Stabellini wrote:
> Hi all,
>
> this series introduces the frontend for the newly introduced PV Calls
> procotol.
>
> PV Calls is a paravirtualized protocol that allows the implementation of
> a set of POSIX functions in a different domain. The PV Calls frontend
> se
On 10/30/2017 11:13 PM, Dongli Zhang wrote:
Hi Boris,
On 10/31/2017 08:58 AM, Boris Ostrovsky wrote:
On 10/30/2017 08:14 PM, Dongli Zhang wrote:
Hi Boris,
On 10/30/2017 09:34 PM, Boris Ostrovsky wrote:
On 10/30/2017 04:03 AM, Dongli Zhang wrote:
After guest live migration on xen, steal
On 10/30/2017 08:14 PM, Dongli Zhang wrote:
Hi Boris,
On 10/30/2017 09:34 PM, Boris Ostrovsky wrote:
On 10/30/2017 04:03 AM, Dongli Zhang wrote:
After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock
On 10/30/2017 05:42 PM, Stefano Stabellini wrote:
> On Mon, 30 Oct 2017, Boris Ostrovsky wrote:
>> On 10/30/2017 03:48 PM, Stefano Stabellini wrote:
>>> On Mon, 30 Oct 2017, Boris Ostrovsky wrote:
>>>> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1))
>
On 10/30/2017 03:48 PM, Stefano Stabellini wrote:
> On Mon, 30 Oct 2017, Boris Ostrovsky wrote:
>>
>> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1))
> Hi Boris, I am trying to repro the warnings below. I have been
> unsuccessful so far. What system are you usin
On 10/26/2017 04:45 PM, Boris Ostrovsky wrote:
> On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
>> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
>>>> Also add pvcalls-front to the Makefile.
>>>>
>&
On 10/30/2017 04:03 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_c
itself does not support 5 level
paging.
So when reading/writing a MFN from/to a pte don't use the kernel's
PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
On 10/27/2017 04:16 AM, Sander Eikelenboom wrote:
On 27/10/17 00:30, Boris Ostrovsky wrote:
On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:
- Enabling the xen pt logging in qemu spit out some things, i wonder if they
are normal:
qemu-system-i386: -serial pty: char device
On 10/05/2017 03:58 PM, Stefano Stabellini wrote:
> On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote:
>> rwlock.h should not be included directly. Instead linux/splinlock.h
>> should be included. One thing it does is to break the RT build.
>>
>> Cc: Stefano Stabellini
>> Cc: xen-de...@lists.xen
On 10/26/2017 10:12 AM, Boris Ostrovsky wrote:
> On 10/26/2017 05:50 AM, Juergen Gross wrote:
>> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>> online new memory initially") introduced a regression when booting a
>> HVM domain with
On 10/25/2017 12:46 PM, Boris Ostrovsky wrote:
> On 10/25/2017 11:08 AM, Juergen Gross wrote:
>> In case gntdev_mmap() succeeds only partially in mapping grant pages
>> it will leave some vital information uninitialized needed later for
>> cleanup. This will lead to an out o
On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:
> Hi Boris / Andrew,
>
> In the aftermath of the linux mmap path I have some questions regarding
> pci-passthrough:
>
> - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to
> be a supported combination ?
I thought it is. I
On 10/26/2017 04:49 PM, Stefano Stabellini wrote:
> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>> On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
>>> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>>>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
>>>&g
On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
>>> Also add pvcalls-front to the Makefile.
>>>
>>> Signed-off-by: Stefano Stabellini
>>> CC: boris
On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> Also add pvcalls-front to the Makefile.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Reviewed-by: Boris Ostrovsky
___
Xen-devel m
ive socket for the purpose of being accepted. If so, free that as
> well.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.
ckets and free them all, one at a time.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ning process at once.
>
> Cc: # 4.13
> Fixes: 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>online new memory initially")
>
> Reported-by: Simon Gaiser
> Suggested-by: Boris Ostrovsky
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 10/25/2017 07:00 PM, Stefano Stabellini wrote:
> On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
>> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
>>> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
>>> in_mutex and out_mutex to avoid concurre
On 10/25/2017 04:05 PM, Sander Eikelenboom wrote:
> Hi Juergen and Boris,
>
> While testing out linux 4.14-rc6 i found some trouble with one of my devices
> for which I use pci-passthrough.
> It fails to start a HVM when configured to use pci-passthrough on this
> particular device (see below fo
ages.
>
> So just initialize the data needed for unmapping the pages a little bit
> earlier.
>
> Cc:
> Reported-by: Arthur Borsboom
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@li
On 10/25/2017 02:45 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_c
On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> Also add pvcalls-front to the Makefile.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/Kconfig | 9 +
> drivers/xen/Makefile | 1 +
> 2 files changed, 10 insertions(+)
>
On 10/24/2017 01:33 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 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map, bool locked)
> +{
> +}
> +
> static const struct xenbus_device_id pvcalls_front_ids[] = {
> { "pvcalls" },
>
!vpmu->arch_vpmu_ops->do_interrupt(regs) )
return;
As result of this extra call VPMU no longer works for PV guests on Intel
because we effectively lose value of MSR_CORE_PERF_GLOBAL_STATUS.
Signed-off-by: Boris Ostrovsky
---
This should also go into 4.9
xen/arch/x86/cpu/vpmu.c | 4
On 10/24/2017 10:41 AM, Juergen Gross wrote:
> On 24/10/17 16:33, Boris Ostrovsky wrote:
>> On 10/24/2017 04:10 AM, Juergen Gross wrote:
>>> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>>> online new memory initially") introduced
ning process at once.
>
> Cc: # 4.13
> Fixes: 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>online new memory initially")
>
> Suggested-by: Boris Ostrovsky
> Signed-off-by: Juergen Gross
Reported-by: HW42
> ---
> drivers/xen/xen-balloon.c | 18
(I just noticed that I missed this patch, sorry)
On 10/06/2017 08:30 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 al
On 10/23/2017 07:06 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>>> +static unsigned int pvcalls_front_poll_passive(struct file *file,
>>> + struct pvcalls_bedata *bedata,
>>> +
On 10/23/2017 07:03 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
>>> + /*
>>> +* Backend only supports 1 inflight accept request, will return
>>> +* errors f
On 10/20/2017 04:35 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Boris Ostrovsky
>> Sent: 19 October 2017 18:45
>> To: Paul Durrant ; x...@kernel.org; xen-
>> d
On 10/19/2017 09:31 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
>>> +int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int
>>> addr_len)
>>> +{
&
On 10/19/2017 09:41 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>>> +static int __write_ring(struct pvcalls_data_intf *intf,
>>> + struct pvcalls_data *data,
>>> + struct iov_iter *msg_iter,
&
On 10/19/2017 09:38 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>>> +
>>> +int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t
>>> len,
>>> +int flags)
>>> +{
>&g
On 10/19/2017 09:26 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
>> with one question:
>>
>>> + /*
>>> +* PVCalls only supports domain AF_INET,
>>> +*
On 10/20/2017 01:37 AM, Dongli Zhang wrote:
> Hi Boris,
>
> - boris.ostrov...@oracle.com wrote:
>
>> On 10/19/2017 04:02 AM, Dongli Zhang wrote:
>>> After guest live migration on xen, steal time in /proc/stat
>>> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
>>> xen_steal_lo
call through to the approprate
> xlate_mmu function if the feature is present. A check is also added
> to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
> should not be used in an HVM tools domain.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Boris Ostrovsk
On 10/19/2017 04:02 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_c
>
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> +
> +
> +int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t
> len,
> + int flags)
> +{
> + struct pvcalls_bedata *bedata;
> + int ret;
> + struct sock_mapping *map;
> +
> + if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
> +
> +static int __write_ring(struct pvcalls_data_intf *intf,
> + struct pvcalls_data *data,
> + struct iov_iter *msg_iter,
> + int len)
> +{
> + RING_IDX cons, prod, size, masked_prod, masked_cons;
> + RING_IDX array_size = XEN_FLEX
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
1 - 100 of 3023 matches
Mail list logo
