ping
On 11/17/2017 10:08 AM, Oleksandr Andrushchenko wrote:
ping
On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:
Hi, all!
Foreword
This RFC is aimed to introduce support of para-virtualized sound
frontend
driver for Xen [1] and gather opinions from the relevant communities
>>> On 11.12.17 at 12:06, wrote:
> On 11/12/17 09:14, Jan Beulich wrote:
> On 08.12.17 at 13:42, wrote:
>>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>> On 24.10.17 at 12:19, wrote:
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed
> to a
> DOMCTL)
>>> On 08.12.17 at 16:11, wrote:
> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
> which should have been 0x020c.
This part of the description has become partly stale now with the
new patch 3.
Jan
___
Xen-devel mailing list
On 11/12/17 09:14, Jan Beulich wrote:
On 08.12.17 at 13:42, wrote:
>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>> On 24.10.17 at 12:19, wrote:
HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to
a
DOMCTL) for consistency with its HVMOP_altp2m_set_
On Mon, Dec 11, 2017 at 5:59 AM, Minjun Hong wrote:
> Hello, I'm working on the 'credit scheduler' of Xen.
> And I need to compare CPU cache misses between original Xen and my patching
> version.
> But I failed all attempt even if I have tried many methods by googling.
> When I typed 'perf list' w
On 11/12/17 10:06, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
>> On 08/12/17 08:03, Tim Deegan wrote:
>>> It should be possible to do something like the misconfigured-entry bit
>>> trick by _allocating_ the memory up-front and building the p2m entries
>>> but only making them usable by t
Hi,
On 08/12/17 10:56, George Dunlap wrote:
> On 12/07/2017 07:21 PM, Marc Zyngier wrote:
>> On 07/12/17 18:06, George Dunlap wrote:
>>> On 12/07/2017 04:58 PM, Marc Zyngier wrote:
On 07/12/17 16:44, George Dunlap wrote:
> On 12/07/2017 04:04 PM, Julien Grall wrote:
>> Hi Jan,
>>
>>> On 11.12.17 at 12:11, wrote:
> On 11/12/17 10:06, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entr
>>> On 08.12.17 at 13:42, wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
> On 24.10.17 at 12:19, wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart
>>> (and
>>> hence with t
>>> On 08.12.17 at 20:05, wrote:
> On 12/8/2017 12:49 AM, Jan Beulich wrote:
>> I'm not convinced of re-using E820 types here. I can see that this
>> might ease the consumption in Linux, but I don't think there should
>> be any connection to x86 aspects here - the data being supplied is
>> x86-agn
On 12/11/2017 11:10 AM, Andre Przywara wrote:
> Hi,
>
> On 08/12/17 10:56, George Dunlap wrote:
>> On 12/07/2017 07:21 PM, Marc Zyngier wrote:
>>> On 07/12/17 18:06, George Dunlap wrote:
On 12/07/2017 04:58 PM, Marc Zyngier wrote:
> On 07/12/17 16:44, George Dunlap wrote:
>> On 12/07/
On 11/12/17 11:09, Jan Beulich wrote:
On 08.12.17 at 16:11, wrote:
>> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
>> which should have been 0x020c.
>
> This part of the description has become partly stale now with the
> new patch 3.
Indeed. I'll wait for other co
flight 72629 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72629/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
test-amd64-a
>>> On 08.12.17 at 15:38, wrote:
> On 08/12/17 08:03, Tim Deegan wrote:
>> It should be possible to do something like the misconfigured-entry bit
>> trick by _allocating_ the memory up-front and building the p2m entries
>> but only making them usable by the {IO}MMUs on first access. That
>> would
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> On 11/12/17 09:14, Jan Beulich wrote:
>> On 08.12.17 at 13:42, wrote:
On 12/08/2017 02:18 PM, Jan Beulich wrote:
On 24.10.17 at 12:19, wrote:
>> HVMOP_altp2m_set_mem_access_multi has been added
Thanks for your answer, George.
What I want ultimately is cache misses from the guest, but even I could not
get the cache misses from dom0 also.
That's why I'm confused as I know, it should be possible to get
cache-misses from dom0 (is it right??).
I already enabled CONFIG_XEN_HAVE_VPMU of current
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12:06, wrote:
>>> My suggestion was that we don't break usecases. The Intel usecase
>>> specifically is for an in-guest entity to have full control of all
>>> altp2m functionality, and this is fine
* Juergen Gross wrote:
> On 11/12/17 11:09, Jan Beulich wrote:
> On 08.12.17 at 16:11, wrote:
> >> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
> >> which should have been 0x020c.
> >
> > This part of the description has become partly stale now with the
> > new
On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote:
>
> Thanks for your answer, George.
>
> What I want ultimately is cache misses from the guest, but even I could not
> get the cache misses from dom0 also.
> That's why I'm confused as I know, it should be possible to get cache-misses
> from dom
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>> On 11.12.17 at 12:06, wrote:
My suggestion was that we don't break usecases. The Intel usecase
specifically is for an in-guest entity to have full control o
On 12/11/2017 01:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>> On 11.12.17 at 12:06, wrote:
My suggestion was that we don't break usecases. The Intel usecase
specifically is for an in-guest entity to have full control o
On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
> On 12/11/2017 03:36 PM, Jan Beulich wrote:
> On 11.12.17 at 13:50, wrote:
>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>> On 11.12.17 at 12:06, wrote:
> My suggestion was that we don't break usecases. The Intel usecase
> specifi
On 12/11/2017 02:51 PM, George Dunlap wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> My suggestion was that we do
>>> On 11.12.17 at 15:50, wrote:
> On 12/11/2017 01:36 PM, Jan Beulich wrote:
> On 11.12.17 at 13:50, wrote:
>>> You argued that we should keep PV linear pagetables, before knowing that
>>> NetBSD used them, in spite of having discovered two *actual*
>>> vulnerabilities in the implementation.
On Thu, Dec 07, 2017 at 04:51:32AM -0700, Jan Beulich wrote:
> >>> On 04.12.17 at 11:24, wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -962,7 +962,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > }
> > else
> > end = 0;
>
>>> On 11.12.17 at 15:46, wrote:
> Quite likely I'm not grasping the full meaning of your objection,
> however the added code is merely another interface to already existing
> core code - so while admittedly there's room for improvement for the EPT
> code below it, this patch really only extends t
>>> On 11.12.17 at 15:51, wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> My suggestion was that we don't break u
On 12/11/2017 09:36 AM, Meng Xu wrote:
> On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote:
>> Thanks for your answer, George.
>>
>> What I want ultimately is cache misses from the guest, but even I could not
>> get the cache misses from dom0 also.
>> That's why I'm confused as I know, it should
On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote:
> >>> On 04.12.17 at 11:24, wrote:
> > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
> > (x86: make Xen early boot code relocatable) is not reliable. Potentially
> > its value may fall below PFN_DOWN(__pa(_end))
>
On Mon, Dec 11, 2017 at 3:05 PM, Boris Ostrovsky
wrote:
> On 12/11/2017 09:36 AM, Meng Xu wrote:
>> On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote:
>>> Thanks for your answer, George.
>>>
>>> What I want ultimately is cache misses from the guest, but even I could not
>>> get the cache misses
On 12/11/2017 02:58 PM, Jan Beulich wrote:
On 11.12.17 at 15:50, wrote:
>> On 12/11/2017 01:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
You argued that we should keep PV linear pagetables, before knowing that
NetBSD used them, in spite of having discovered two *ac
On 12/11/2017 03:05 PM, Jan Beulich wrote:
On 11.12.17 at 15:51, wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12:06, wrot
On 12/11/2017 05:54 PM, George Dunlap wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
> On 11.12.17 at 15:51, wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan
On Mon, Dec 11, 2017 at 8:05 AM, Jan Beulich wrote:
On 11.12.17 at 15:51, wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12
On 12/11/2017 06:00 PM, Tamas K Lengyel wrote:
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there. The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to r
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
wrote:
> From: Razvan Cojocaru
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
wrote:
> From: Razvan Cojocaru
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2
>>> On 11.12.17 at 16:54, wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
> On 11.12.17 at 15:51, wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wro
flight 117058 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117058/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
On Fri, Nov 03, 2017 at 11:56:27AM +, Owen Smith wrote:
> Improve the input device model in xenfb, by updating the
> Qemu input handlers and adding a feature to allow for
> raw (unscaled) absolute coordinates to be represented.
>
> Changes:
> * use keycodedb to generate qcode to linux input
flight 117061 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117061/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote:
> Previously, some fields (reserved or unalterable) are filtered by
> Qemu. This fields are useless for the legacy interrupt format.
> However, these fields are may meaningful (for intel platform)
> for the interrupt of remapping format. It
On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
> Interrupt Remapping -> Interrupt Request Formats On Intel 64
> Platforms, fields of MSI data register have changed. This patch
> avoids wrongly regarding a remappable fo
flight 117059 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117059/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
flight 117062 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117062/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
flight 117056 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117056/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-i386
Hi,
On 12/10/2017 03:22 PM, Tim Deegan wrote:
At 14:38 + on 08 Dec (1512743913), Julien Grall wrote:
On 08/12/17 08:03, Tim Deegan wrote:
+1 for avoiding the full majesty of PoD if you don't need it.
It should be possible to do something like the misconfigured-entry bit
trick by _allocati
flight 117057 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117057/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
test-arm64-arm
Hi Jan,
On 12/11/2017 10:06 AM, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the
On 12/11/2017 11:10 AM, Andre Przywara wrote:
Hi,
Hi Andre,
But on the other hand we had PoD naturally already in KVM, so this came
at no cost.
So I believe it would be worth to investigate what the actual impact is
on booting a 32-bit kernel, with emulating s/w ops like KVM does (see
below),
On 08/12/2017 09:49, Jan Beulich wrote:
>> + * The layout of each entry in the memory map table is as follows and no
>> + * padding is used between entries in the array:
>> + *
>> + * 0 ++
>> + *| addr | Base address
>> + * 8 ++
>> + *| size
flight 117082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117082/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
test-arm64-arm
On Wed, 9 Aug 2017, Mirela Simonovic wrote:
> This document contains our draft proposal for implementing "suspend to RAM"
> support for ARM in Xen, as discussed during the last Xen ARM community call.
> It covers the basic suspend to RAM mechanism based on ARM PSCI standard,
> that would allow indi
On Wed, 1 Nov 2017, Julien Grall wrote:
> - Remove spurious ()
> - Add missing spaces
> - Turn 1 << to 1UL <<
> - Rename spfn to smfn and switch to mfn_t
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> Cc: Stefano Stabellini
>
> Changes in v2:
On Wed, 1 Nov 2017, Julien Grall wrote:
> The arm32 version of the function is_xen_heap_page currently define a
> variable _mfn. This will lead to a compiler when use typesafe MFN in a
> follow-up patch:
>
> called object '_mfn' is not a function or function pointer
>
> Fix it by renaming the loc
On Wed, 1 Nov 2017, Julien Grall wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
>
> So make __page_to_mfn and __mfn_to_page return mfn_t by default.
>
> Only
On Thu, 9 Nov 2017, Jan Beulich wrote:
> >>> On 09.11.17 at 16:48, wrote:
> > On 09/11/17 15:47, Jan Beulich wrote:
> > On 09.11.17 at 16:39, wrote:
> >>> What I meant is you would replace the 4 occurrences by
> >>> mfn_to_page(_mfn(...)). If you are happy with that, then fine.
> >>
> >> Oh,
Hi Stefano,
On 12/11/2017 11:37 PM, Stefano Stabellini wrote:
On Thu, 9 Nov 2017, Jan Beulich wrote:
On 09.11.17 at 16:48, wrote:
On 09/11/17 15:47, Jan Beulich wrote:
On 09.11.17 at 16:39, wrote:
What I meant is you would replace the 4 occurrences by
mfn_to_page(_mfn(...)). If you are hap
Hi Stefano,
On 12/08/2017 10:43 PM, Stefano Stabellini wrote:
On Fri, 8 Dec 2017, Julien Grall wrote:
On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 06/12/17 12:27, Julien Grall wrote:
> > On 12/06/2017 01:26 AM, Stefano Stabe
On Tue, 12 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 12/08/2017 10:43 PM, Stefano Stabellini wrote:
> > On Fri, 8 Dec 2017, Julien Grall wrote:
> > > On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
> > >On Fri, 8 Dec 2017, Julien Grall wrote:
> > >> On 06/12/17 12:27, Ju
Thanks Bjorn for your review comments. Please see below for my comments.
On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices ba
flight 117083 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117083/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
test-arm64-arm
On Mon, Dec 11, 2017 at 06:29:29PM -0600, Govinda Tatti wrote:
>
> Thanks Bjorn for your review comments. Please see below for my comments.
>
> On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
> >On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
> >>This patch exports pcie_has_flr() and it
On Mon, Dec 11, 2017 at 05:59:08PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote:
>> Previously, some fields (reserved or unalterable) are filtered by
>> Qemu. This fields are useless for the legacy interrupt format.
>> However, these fields are may meaningf
On Mon, Dec 11, 2017 at 06:07:48PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
>> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
>> Interrupt Remapping -> Interrupt Request Formats On Intel 64
>> Platforms, fields of MSI data register
flight 117060 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117060/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
From: Elena Ufimtseva
It is expected that the symbol has type STT_FUNC in livpatch.ignore.functions
sections, but it is incorrect and results in functions not to be ignored.
To actually ignore functions in livepatch.ignore.functions section, attempt to
find the symbol of type STT_FUNC by its name
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge
---
arch/x86/kernel/itmt.c | 1 -
arch/x86/kernel/process.c | 1 -
arch/x86/kernel/setup.c| 1 -
arch/x8
On 11/12/17 21:42, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge
Reviewed-by: Juergen Gross
Juergen
__
On Tue, Dec 12, 2017 at 12:30 AM, George Dunlap wrote:
> On Mon, Dec 11, 2017 at 3:05 PM, Boris Ostrovsky
> wrote:
> > On 12/11/2017 09:36 AM, Meng Xu wrote:
> >> On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong
> wrote:
> >>> Thanks for your answer, George.
> >>>
> >>> What I want ultimately is ca
>>> On 11.12.17 at 21:26, wrote:
> On 12/11/2017 10:06 AM, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m
71 matches
Mail list logo
