On 22/06/16 12:21, Wei Liu wrote:
> On Wed, Jun 22, 2016 at 10:37:24AM +0100, David Vrabel wrote:
>> On 22/06/16 09:38, Paulina Szubarczyk wrote:
>>> In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
>>> system call is invoked. In mini-os the operation is y
On 22/06/16 14:29, Wei Liu wrote:
> On Wed, Jun 22, 2016 at 01:37:50PM +0100, David Vrabel wrote:
>> On 22/06/16 12:21, Wei Liu wrote:
>>> On Wed, Jun 22, 2016 at 10:37:24AM +0100, David Vrabel wrote:
>>>> On 22/06/16 09:38, Paulina Szubarczyk wrote:
>>
: David Vrabel
---
Cc: Kevin Moraga
v3:
- fold mask_rw_pte()/mask_rw_pteval() into their callers.
v2:
- Remove __init annotation from xen_make_pte_init() since
PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
- mask_rw_pte() -> mask_rw_pteval() for x86-64.
---
arch/x86/xen/mmu.c |
On 21/06/16 19:26, Andrey Grodzovsky wrote:
> Current overlap check is evaluating to false a case where a filter field
> is fully contained (proper subset) of a r/w request.
> This change applies classical overlap check instead to include
> all the scenarios.
>
> More specifically, for (Hilscher G
On 23/06/16 06:12, Juergen Gross wrote:
> xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
> bound of the loop setting non-kernel-image entries to zero should not
> exceed the size of level2_kernel_pgt.
Applied to for-linus-4.7b, thanks.
David
On 23/06/16 13:13, Juergen Gross wrote:
> On 23/06/16 11:51, David Vrabel wrote:
>> When page tables entries are set using xen_set_pte_init() during early
>> boot there is no page fault handler that could handle a fault when
>> performing an M2P lookup.
>>
>&g
On 23/06/16 14:27, Juergen Gross wrote:
> On 23/06/16 15:06, David Vrabel wrote:
>> On 23/06/16 13:13, Juergen Gross wrote:
>>> On 23/06/16 11:51, David Vrabel wrote:
>>>> When page tables entries are set using xen_set_pte_init() during early
>>>> boot
On 06/06/16 10:33, Stefano Stabellini wrote:
> # Goals
>
> The goal of the protocol is to provide networking capabilities to any
> guests, with the following added benefits:
>
> * guest networking should work out of the box with VPNs, wireless
> networks and any other complex network configurat
On 24/06/16 11:21, Jan Beulich wrote:
> A long while back separating out all control kind operations (intended
> for use by only the control domain or device model) from the currect
> hvmop hypercall has been discussed. This series aims at finally making
> this reality (at once allowing to streamli
On 24/06/16 11:35, Jan Beulich wrote:
On 24.06.16 at 12:29, wrote:
>> On 24/06/16 11:21, Jan Beulich wrote:
>>> A long while back separating out all control kind operations (intended
>>> for use by only the control domain or device model) from the currect
>>> hvmop hypercall has been discusse
On 24/06/16 14:37, Jan Beulich wrote:
On 24.06.16 at 15:27, wrote:
>> On 24/06/16 11:35, Jan Beulich wrote:
>> On 24.06.16 at 12:29, wrote:
On 24/06/16 11:21, Jan Beulich wrote:
> A long while back separating out all control kind operations (intended
> for use by only the co
+--
drivers/xen/xen-pciback/conf_space_header.c | 18 ---
4 files changed, 58 insertions(+), 68 deletions(-)
Andrey Grodzovsky (1):
xen/pciback: Fix conf_space read/write overlap check.
David Vrabel (1):
x86/xen: avoid m2p lookup when setting early page table entries
Jan Beulich (1
On 24/06/16 10:13, Jan Beulich wrote:
> Reads following writes with all address bits set to 1 should return all
> changeable address bits as one, not the BAR size (nor, as was the case
> for the upper half of 64-bit BARs, the high half of the region's end
> address). Presumably this didn't cause an
On 07/06/16 07:31, Jan Beulich wrote:
> - drop unused function parameter of read_dev_bar()
> - drop rom_init() (now identical to bar_init())
> - fold read_dev_bar() into its now single caller
> - simplify determination of 64-bit memory resource
> - use const and unsigned
Please split this in 5 sep
On 24/06/16 15:25, Jan Beulich wrote:
>
> And then - what's your expectation? Any parts of this new
> interface can subsequently be marked stable if we so wish. I
> don't see why this needs to happen right away.
Ok.
David
___
Xen-devel mailing list
Xe
On 27/06/16 21:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file c
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn'
identical to the character device
/dev/xen/xenbus so replace the file with a symlink.
Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.
Signed-off-by: David Vrabel
---
v2:
- remove unneeded includes
---
drivers/xen/xenfs/super.c | 10 --
1
simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.
Signed-off-by: David Vrabel
---
v2:
- simplified.
---
fs/libfs.c | 15 +--
include/linux/fs.h | 2 +-
2 files changed, 14 insertions(+
Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file. This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.
This requires extending simple_fill_super() to add sy
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> HYPERVISOR_vcpu_op passes Linux's idea of vCPU id as a parameter while
> Xen's idea is expected. In some cases these ideas diverge so we need to
> do remapping.
>
> There is an issue, however. PV guests do VCPUOP_is_up very early
> (see xen_fill_possibl
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
> these are the first 32 vCPUs from Xen's perspective and we should map them
> accordingly with the newly introduced xen_vcpu_id mapping.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
On 29/06/16 10:16, Vitaly Kuznetsov wrote:
> David Vrabel writes:
>
>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdum
On 27/06/16 08:24, Jan Beulich wrote:
On 24.06.16 at 17:01, wrote:
>> On 07/06/16 07:31, Jan Beulich wrote:
>>> - drop unused function parameter of read_dev_bar()
>>> - drop rom_init() (now identical to bar_init())
>>> - fold read_dev_bar() into its now single caller
>>> - simplify determinat
On 01/06/16 15:15, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency. Replace dedicated xen_pcibk_wq with the
> use of system_wq.
>
> Unlike a dedica
On 31/05/16 17:56, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency. Replace dedicated xenbus_frontend_wq with the
> use of system_wq.
>
> Unlike a
On 29/06/16 16:00, Amitoj Kaur Chawla wrote:
> The kernel.h macro DIV_ROUND_UP performs the computation
> (((n) + (d) - 1) /(d)) but is perhaps more readable.
>
> The Coccinelle script used to make this change is as follows:
> @haskernel@
> @@
>
> #include
>
> @depends on haskernel@
> expressio
On 06/07/16 07:47, Jan Beulich wrote:
> The first five patches are the result of the requested split of
> "xen-pciback: clean up {bar,rom}_init()", with Boris'es R-b
> dropped despite there not being any functional change (the
> mechanical change appears too significant to retain it). The
> remaini
On 06/07/16 06:00, Juergen Gross wrote:
> With most recent Xen hypervisor (4.8) it is now possible to add full
> support of CONFIG_PARAVIRT_TIME_ACCOUNTING.
>
> To be applied on top of commit ed2f61fdd2356c2a1d1239aa1507ce4e2e059306
> "xen: add steal_clock support on x86" of kernel/git/xen/tip.git
On 07/07/16 08:35, Jan Beulich wrote:
> Many of these operations can take arbitrarily long, which can become a
> problem irrespective of them being exposed to privileged users only.
If this is a concern I would rather see large numbers of mapping
requests processed in smaller batches. This would
On 07/07/16 08:35, Jan Beulich wrote:
> There's no reason why this would need to be limited to x86-64.
Did you test it?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 08:48, Jan Beulich wrote:
>
> Signed-off-by: Jan Beulich
> ---
> drivers/video/fbdev/xen-fbfront.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 4.7-rc6-xenbus_scanf.orig/drivers/video/fbdev/xen-fbfront.c
> +++ 4.7-rc6-xenbus_scanf/drivers/video/fbdev/xen-fb
On 07/07/16 08:57, Jan Beulich wrote:
> ... for single items being collected: It is more typesafe (as the
> compiler can check format string and to-be-written-to variable match)
> and requires one less parameter to be passed.
Do not split commit messages between the subject and the body in this
wa
On 07/07/16 08:59, Jan Beulich wrote:
> Only a positive return value indicates success.
This checks were already correct.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 08:57, Jan Beulich wrote:
> Only a positive return value indicates success.
This is not correct.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 09:06, Jan Beulich wrote:
> ... as being the simpler variant.
[...]
> --- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
> +++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback/xenbus.c
> @@ -617,9 +617,9 @@ static int xen_blkbk_probe(struct xenbus
>
On 07/07/16 11:26, David Vrabel wrote:
> On 07/07/16 09:06, Jan Beulich wrote:
>> ... as being the simpler variant.
> [...]
>> --- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
>> +++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback/xenbus.c
>&
On 07/07/16 11:35, Wei Liu wrote:
> On Thu, Jul 07, 2016 at 10:58:16AM +0100, David Vrabel wrote:
>> On 07/07/16 08:57, Jan Beulich wrote:
>>> Only a positive return value indicates success.
>>
>> This is not correct.
>>
>
> Do you mean the commit
On 07/07/16 09:00, Jan Beulich wrote:
> ... as being the simpler variant.
It's really annoying that all these related cleanups where not in the
same thread. Don't do this again, please.
The better clean-up is to remove xenbus_write() in favour of
xenbus_printf() everywhere (especially since one o
On 07/07/16 08:23, Jan Beulich wrote:
> Inability to locate a user mode specified transaction ID should not
> lead to a kernel crash. For other than XS_TRANSACTION_START also
> don't issue anything to xenbus if the specified ID doesn't match that
> of any active transaction.
Applied to for-linus-4
On 07/07/16 08:32, Jan Beulich wrote:
> We must not skip the transaction_end() call for a failed
> XS_TRANSACTION_START. The removed code fragment got introduced by
> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus
> stalling shutdown/restart") without its description really indica
On 07/07/16 13:09, Jan Beulich wrote:
On 07.07.16 at 13:36, wrote:
>> On 07/07/16 08:32, Jan Beulich wrote:
>>> We must not skip the transaction_end() call for a failed
>>> XS_TRANSACTION_START. The removed code fragment got introduced by
>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous
On 07/07/16 13:23, Jan Beulich wrote:
On 07.07.16 at 14:17, wrote:
>> On 07/07/16 13:09, Jan Beulich wrote:
>> On 07.07.16 at 13:36, wrote:
On 07/07/16 08:32, Jan Beulich wrote:
> We must not skip the transaction_end() call for a failed
> XS_TRANSACTION_START. The removed co
On 07/07/16 14:13, David Vrabel wrote:
> On 07/07/16 13:23, Jan Beulich wrote:
>>>>> On 07.07.16 at 14:17, wrote:
>>> On 07/07/16 13:09, Jan Beulich wrote:
>>>>>>> On 07.07.16 at 13:36, wrote:
>>>>> On 07/07/16 08:32, Jan Beulich
On 07/07/16 14:59, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was
> Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"):
>> On 07/07/16 12:10, Lars Kurth wrote:
>>> @Andrew: would something like test/xtf.git work
>
> I would live with that.
>
>> It w
On 07/07/16 14:35, Jan Beulich wrote:
>>>> On 07.07.16 at 15:22, wrote:
>> On 07/07/16 14:13, David Vrabel wrote:
>>> On 07/07/16 13:23, Jan Beulich wrote:
>>>>>>> On 07.07.16 at 14:17, wrote:
>>>>> On 07/07/16 13:09, Jan Beulich wro
On 07/07/16 08:25, Jan Beulich wrote:
> 1: don't bail early from xenbus_dev_request_and_reply()
> 2: simplify xenbus_dev_request_and_reply()
Applied to for-linus-4.7b, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.o
On 08/07/16 13:15, Jan Beulich wrote:
> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
> both Intel and AMD systems. Doing any kind of hardware capability
> checks in the driver as a prerequisite was wron
On 08/07/16 13:53, Jan Beulich wrote:
On 08.07.16 at 14:29, wrote:
>> On 08/07/16 13:15, Jan Beulich wrote:
>>> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
>>> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
>>> both Intel and AMD systems. Doing
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.7b-rc6-tag
xen: bug fixes for 4.7-rc6
- Fix two bugs in the handling of xenbus transactions.
- Make the xen acpi driver compatible with Xen 4.7.
Thanks.
David
drivers/xen/xen-ac
On 08/07/16 15:17, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
>> For single items being collected this should be preferred as being more
>> typesafe (as the compiler can check format string and to-be-written-to
>> variable match) and more efficient (
On 08/07/16 15:16, Stefano Stabellini wrote:
>
> http://pubs.opengroup.org/onlinepubs/7908799/xns/connect.html
Are you really guaranteeing full POSIX semantics for all these calls?
And not say, POSIX-like except where Linux decides to differ because
POSIX is dumb?
How is the guest (which expects
On 08/07/16 12:23, Stefano Stabellini wrote:
>
> XenSocks provides the following benefits:
> * guest networking works out of the box with VPNs, wireless networks and
> any other complex configurations on the host
Only in the trivial case where the host only has one external network.
Otherwise,
On 08/07/16 17:52, Stefano Stabellini wrote:
>
>> c) My belief that most of the advantages of this proposal can be
>> achieved with smarts in the backend.
>
> By backend do you mean netfront/netback? If so, I have already pointed
> out why that is not the case in previous emails as well as in thi
On 11/07/16 04:58, 소병철 wrote:
> Hello everyone :)
>
>
>
> I have a question about xen event channel. Is it possible to allocate
> two event channels in one xen frontend driver?
Yes. For example, netif can have a separate Tx and Rx event channel.
David
___
On 28/06/16 19:06, David Vrabel wrote:
> simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
> The target is provided in the new "link" field.
Can I get an ack for this, please? So it can go into 4.8 via the Xen tree.
David
>
> Signed-off-by
On 11/07/16 10:33, Juergen Gross wrote:
> On 11/07/16 04:51, Bin Wu wrote:
>> During scsi command queueing, if mapping data fails, we need to
>> reclaim the failed request. Otherwise, the garbage request will
>> be pushed into the ring for the backend to work.
>
> Well spotted. There is another in
model (QEMU). e.g., Once the device model as bound to the
ioreq server event channels it can restrict the file handle so an
exploited DM cannot use it to create or bind to arbitrary event
channels.
Signed-off-by: David Vrabel
---
drivers/xen/evtchn.c | 40
On 11/07/16 16:31, Boris Ostrovsky wrote:
> On 07/11/2016 10:57 AM, David Vrabel wrote:
>> diff --git a/include/uapi/xen/evtchn.h b/include/uapi/xen/evtchn.h
>> index 14e833ee4..f057b53 100644
>> --- a/include/uapi/xen/evtchn.h
>> +++ b/include/uapi/xen/evtchn.h
&
On 11/07/16 17:33, Andrew Cooper wrote:
> On 11/07/16 17:15, David Vrabel wrote:
>> On 11/07/16 16:31, Boris Ostrovsky wrote:
>>> On 07/11/2016 10:57 AM, David Vrabel wrote:
>>>> diff --git a/include/uapi/xen/evtchn.h b/include/uapi/xen/evtchn.h
>>>>
being called later.
Prioritising the in-kernel kexec image over the hypervisor one seems
sensible behaviour to me.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 13/07/16 14:07, Wei Liu wrote:
>
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process". The concept of a process is only
> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
> Maybe the OS xenbus driver should reap all watche
On 13/07/16 14:32, Juergen Gross wrote:
> On 13/07/16 15:17, David Vrabel wrote:
>> On 13/07/16 14:07, Wei Liu wrote:
>>>
>>> My gut feeling is that xenstored shouldn't have the knowledge to
>>> associate a watch with a "process". The conce
This series replaces the current read-write lock implementation with
the queued read-write locks from Linux. These are fair; under
contention both readers and writers will be queued and obtain the lock
in FIFO order (due to the fairness of the internal ticket lock).
The implementation is all in C
From: Jennifer Herbert
In preparation for a replacement read-write lock implementation, move
the API and the per-cpu read-write locks into their own files.
Signed-off-by: Jennifer Herbert
Signed-off-by: David Vrabel
---
v3:
- fix XSM build
v2:
- new
---
xen/arch/x86/mm/mem_sharing.c | 1
ning
4 bytes for the arch_spinlock_t.
Architectures that can single-copy adress bytes can optimize
queue_write_unlock() with a 0 write to the LSB (the write count).
We do not yet make use of the architecture-specific optimization noted
above.
Signed-off-by: Jennifer Herbert
Signed-off
On 01/02/16 11:58, Jan Beulich wrote:
> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
> avoiding removal of IOMMU mappings before the driver actually got
> unbound from the device. Naturally we should be using this too.
Because otherwise...? What happens if we don't make thi
On 01/02/16 12:16, Jan Beulich wrote:
On 01.02.16 at 13:01, wrote:
>> On 01/02/16 11:58, Jan Beulich wrote:
>>> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
>>> avoiding removal of IOMMU mappings before the driver actually got
>>> unbound from the device. Naturally we s
On 20/12/15 06:56, Tian, Kevin wrote:
>> From: David Vrabel [mailto:david.vra...@citrix.com]
>> Sent: Friday, December 18, 2015 9:51 PM
>>
>> Holding the p2m lock while calling ept_sync_domain() is very expensive
>> since it does a on_selected_cpus() call. IPIs on
On 22/12/15 12:23, George Dunlap wrote:
> On 18/12/15 13:50, David Vrabel wrote:
>> Holding the p2m lock while calling ept_sync_domain() is very expensive
>> since it does a on_selected_cpus() call. IPIs on many socket machines
>> can be very slows and on_selected_cpus() is
This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:
a) Deferring invalidations until the p2m write lock is released.
Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160
freeing a page table page (since partial translations may be
cached).
2. When reclaiming a zero page as part of PoD.
For these cases, add p2m_tlb_flush_sync() calls which will immediately
perform the invalidate before the page is freed or reclaimed.
Signed-off-by: David Vrabel
---
v7:
- Add some
since there are apparently systems
where the NMI works only once.
This will also slightly speed up boot times since we only wait the
full 10 ticks if the NMI watchdog on one or more CPUs is not working.
Signed-off-by: David Vrabel
---
v2:
- Check for two watchdog NMIs.
---
xen/arch/x86/nmi.c
On 01/02/16 18:00, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
Reviewed-by: David Vrabel
Thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 02/02/16 10:11, Andrew Cooper wrote:
> On 02/02/16 07:40, Li, Liang Z wrote:
>> Hi David,
>>
>> We found dom0 will crash when booing on HSW-EX server, the dom0 kernel
>> version is v4.4. By debugging I found the your patch
>> ' x86/xen: discard RAM regions above the maximum reservation' , which
On 02/02/16 06:20, Dongli Zhang wrote:
> While npo.copy and npo.meta are initialized in xenvif_rx_action, fields
> such as npo.meta_prod are directly used later in xenvif_gop_skb without
> being initialized first. Although the output of xenvif_rx_action is based
> on the difference between new npo-
On 02/02/16 12:44, Jan Beulich wrote:
> All,
>
> while looking into some of the DEBUG_WX issues I came across
> aforementioned function and started wondering how pv-ops gets
> away without the unmapping XenoLinux has always been doing
> (in free_init_pages()).
Um. I'm not sure why you think some
On 02/02/16 13:15, Li, Liang Z wrote:
We found dom0 will crash when booing on HSW-EX server, the dom0
kernel version is v4.4. By debugging I found the your patch '
x86/xen: discard RAM regions above the maximum reservation' , which
>> the commit ID is : f5775e0b6116b7e2425ccf535243b2
On 02/02/16 14:10, Jan Beulich wrote:
On 02.02.16 at 14:30, wrote:
>> On 02/02/16 12:44, Jan Beulich wrote:
>>> All,
>>>
>>> while looking into some of the DEBUG_WX issues I came across
>>> aforementioned function and started wondering how pv-ops gets
>>> away without the unmapping XenoLinux
On 01/02/16 15:38, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
Acked-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
ise).
Otherwise,
Reviewed-by: David Vrabel
David
> Signed-off-by: Boris Ostrovsky
> ---
> arch/x86/xen/grant-table.c |4 ++--
> drivers/xen/grant-table.c |8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/xen/grant-table.c b/ar
On 01/02/16 15:38, Boris Ostrovsky wrote:
> Subsequent patch will add support for starting secondary VCPUs in
> HVMlite guest. This patch exists to simmplify code review.
>
> No functional changes (except for introduction of 'if (!xen_hvmlite)').
Acked-by
This needs some more description in the commit message.
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
[...]
> + hctxt->cpu_regs.x86_32.cs_base = 0;
> + hctxt->cpu_regs.x86_32.cs_limit = ~0u;
> + hctxt->cpu_regs.x86_32.cs_ar = 0xc9b;
> + hctxt
On 01/02/16 15:38, Boris Ostrovsky wrote:
> xen_timer_init() will be called from apic_bsp_setup().
I must be missing something because xen_init_time_ops() is only called
from the PV-only xen_start_kernel()?
David
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -492,7 +492,10 @@ void
On 01/02/16 15:38, Boris Ostrovsky wrote:
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -29,6 +29,12 @@ extern enum xen_domain_type xen_domain_type;
> #define xen_initial_domain() (0)
> #endif /* CONFIG_XEN_DOM0 */
>
> +#ifdef CONFIG_XEN_PVHVM
> +extern int xen_hvmlite;
> +#els
On 03/02/16 05:46, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
You forgot the previous Reviewed-by tags.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 03/02/16 11:28, Jan Beulich wrote:
On 01.02.16 at 12:31, wrote:
>> +void queue_write_lock_slowpath(rwlock_t *lock)
>> +{
>> +u32 cnts;
>> +
>> +/* Put the writer into the wait queue. */
>> +spin_lock(&lock->lock);
>> +
>> +/* Try to acquire the lock directly if no reader is
On 01/02/16 15:38, Boris Ostrovsky wrote:
> HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
> for example, will complain.
I think we should consider always giving HVMlite guests an emulated
APIC. I think this eliminates one of the biggest differences between
HVMlite and n
On 02/02/16 16:58, Boris Ostrovsky wrote:
> On 02/02/2016 11:21 AM, David Vrabel wrote:
>> This needs some more description in the commit message.
>>
>>> --- a/arch/x86/xen/smp.c
>>> +++ b/arch/x86/xen/smp.c
>> [...]
>>> +hctxt-
On 01/02/16 15:38, Boris Ostrovsky wrote:
> HVMlite secondary VCPUs use baremetal bringup path (i.e. native_*
> smp_ops) but need to do some preparation in PV code.
If we always provided an emulated APIC could we use the native SMP
bring-up instead?
David
___
On 04/02/16 21:04, hanji unit wrote:
> Hello, does Xen support sharing memory pages between multiple domains
> (such as as Dom0, DomU1, DomU2)? The Grant Table hypercalls seem
> limited to:
>
> IOCTL_GNTALLOC_ALLOC_GREF
> IOCTL_GNTALLOC_DEALLOC_GREF
> IOCTL_GNTALLOC_SET_UNMAP_NOTIFY
These are the
On 08/02/16 12:10, Stefano Stabellini wrote:
> On Fri, 5 Feb 2016, Andrew Cooper wrote:
>> The current pci-front/back and Qemu-based methods have substantial
>> architectural deficiencies, and are incredibly fragile to change. When
>> was the last XSA to PCI Passthrough which didn't end up requiri
On 06/02/16 21:38, Doug Goldstein wrote:
> Hi all,
>
> Given that pvgrub2 has been available for a while now and Ian did a good
> write up on the Xen blog of how to use it and a few downstream distros
> are starting to pick it up as the way to boot Xen images. Plus most
> downstreams switching exc
On 08/02/16 14:30, Juergen Gross wrote:
> When adding more than one LUN to a frontend a warning for a failed
> assignment is issued in dom0 for each already existing LUN. Avoid this
> warning by checking for a LUN already existing when existence is
> allowed (scsiback_do_add_lun() called with try =
On 08/02/16 16:50, Juergen Gross wrote:
> On 08/02/16 17:46, David Vrabel wrote:
>> On 08/02/16 14:30, Juergen Gross wrote:
>>> When adding more than one LUN to a frontend a warning for a failed
>>> assignment is issued in dom0 for each already existing LUN. Avoid this
On 09/02/16 16:15, Jan Beulich wrote:
On 09.02.16 at 16:06, wrote:
>> On Tue, 9 Feb 2016, Jan Beulich wrote:
>>> Will STAO be sufficient for everything that may need customization?
>>> I'm particularly worried about processor related methods in DSDT or
>>> SSDT, which - if we're really meanin
On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -576,6 +578,7 @@ static void pcifront_free_roots(struct pcifront_device
> *pdev)
> free_root_bus_devs(bus_entry->bus);
>
> kfree(bus_entry->bus-
On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> These are patches that were developed for the Debian bug
> 810379 which san Tommi had openned.
>
> The issue around from the two XSA fixes - which introduced
> this regression.
Applied to for-linus-4.6, thanks.
I rewrote some of the com
On 15/02/16 14:35, David Vrabel wrote:
> On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
>> Hey,
>>
>> These are patches that were developed for the Debian bug
>> 810379 which san Tommi had openned.
>>
>> The issue around from the two XSA fixes - which intr
On 15/02/16 16:51, Stefano Stabellini wrote:
> CC'ing a few others.
>
> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
>> The Xen framebuffer driver selects the xen keyboard driver, so the latter
>> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
>> is a loadable module, this confi
501 - 600 of 1518 matches
Mail list logo
