>>> On 18.05.17 at 20:09, wrote:
> On Mon, 15 May 2017, Wei Liu wrote:
>> On Sat, May 13, 2017 at 10:28:27AM +0800, Zhongze Liu wrote:
>> > Stefano wrote:
>> > "I think that in your scenario Xen (the hypervisor) wouldn't allow the
>> > first domain to be completely destroyed because it knows that
Hi Jan,
On 19/05/2017 07:47, Jan Beulich wrote:
On 18.05.17 at 17:38, wrote:
Modify Config.mk and Kconfig.debug to disable debug by default in
preparation for late RCs and eventual release.
Signed-off-by: Julien Grall
To avoid pointless code churn on the master branch, shouldn't this
be do
Hi,
On 18/05/2017 15:15, osstest service owner wrote:
flight 109557 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109557/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 6 xen-boot
Hi Jan,
On 19/05/2017 07:16, Jan Beulich wrote:
On 18.05.17 at 17:12, wrote:
On 18/05/17 09:41, Jan Beulich wrote:
The compiler dislikes duplicat "const", and the ones it complains about
s/duplicat/duplicate/
look like they we in fact meant to be placed differently.
Also fix array_access
>>> On 17.05.17 at 16:59, wrote:
> On 05/16/2017 06:43 PM, osstest service owner wrote:
>> flight 109469 linux-linus real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/109469/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not
>>> On 19.05.17 at 09:46, wrote:
> On 18/05/2017 15:15, osstest service owner wrote:
>> test-amd64-amd64-amd64-pvgrub 9 debian-di-install fail REGR. vs.
>> 109486
>> test-amd64-i386-xl-raw 18 guest-start/debian.repeat fail REGR. vs.
>> 109486
>> test-amd64-amd64-xl-qemut-stubdom-d
flight 109581 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109581/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail blocked in
109486
test-armhf-armhf-xl-rtds
flight 71350 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71350/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
Hi, Jan
On Fri, May 19, 2017 at 9:30 AM, Jan Beulich wrote:
On 18.05.17 at 19:41, wrote:
>> patch #6: As for the current patch, likely the "init" platform
>> callback should be extended with
>> extra "use_iommu" argument as well as the "iommu_domain_init" API. In
>> that case we
>> would ju
flight 109596 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109596/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f78c8bf2c64f57d5148bea1a56ade2218a13e4d7
baseline version:
ovmf 7a85e8474127ae6df4733
On 05/17/2017, 03:23 PM, Jiri Slaby wrote:
>> So the initial CFI state is different between the two types of
>> "functions". And there are a lot of other differences. C-type
>> functions have to follow frame pointer conventions, for example. So
>> your FUNC_START macro (and objtool) would have t
On Thu, May 18, 2017 at 11:09:40AM -0700, Stefano Stabellini wrote:
> > >
> > > Yes, those attributes are necessary and should be explicitly specified in
> > > the
> > > config file. I'll add them in the next version of this proposal. And
> > > taking the
> > > granularity into consideration, wh
Hi list,
I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
yes I know - very old ;-), but the affected code hasn't much changed.
The panic was never seen before and occured while booting the system,
only dom0 was running.
(XEN) Xen BUG at timer.c:189
(XEN) [ Xen-4.4.3_
Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> On 18.05.17 at 17:38, wrote:
> > Modify Config.mk and Kconfig.debug to disable debug by default in
> > preparation for late RCs and eventual release.
> >
> > Signed-off-by: Julien Grall
>
> To avoid pointless code churn on th
Hi, George.
Per your suggesion, I tried to add some code to xenalyze.c to analyze
some newly added events. To have more understanding, you can read the
patch at the bottom. In this patch, I try to count how many times a
given vcpu is added and removed from a pi blocking list. After
collecting some
Jan Beulich writes ("Re: [Xen-devel] [linux-linus test] 109469: regressions -
FAIL"):
> Therefore I'm afraid the only way we could obtain a more
> complete picture would be if this re-occurred and if at that
> time we'd have "async-show-all" in place on the hypervisor
> command line.
Is that a th
flight 109583 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 107636
test-amd64-i386-q
flight 109609 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> format. The original code isn't suitable to the new format. A new pair
> bind/unbind interfaces are added for this usage. This patch recogn
>>> On 27.04.17 at 16:35, wrote:
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -11,7 +11,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
> if (d_config->b_info.device_model_version !=
>
>>> On 19.05.17 at 12:56, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [linux-linus test] 109469: regressions -
> FAIL"):
>> Therefore I'm afraid the only way we could obtain a more
>> complete picture would be if this re-occurred and if at that
>> time we'd have "async-show-all" in place on the
In the original code, top-level dist target unconditionally invokes
dist target for tools/include, which is wrong when tools component is
not enabled.
Make dist-tools depend on dist-tools-public-headers, which depends on
build-tools-public-headers.
Discovered by Travis-CI.
Signed-off-by: Wei Liu
On Thu, May 18, 2017 at 01:33:00AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> 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 re
>>> On 19.05.17 at 13:16, wrote:
> On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
>> --- a/include/hw/i386/apic-msidef.h
>> +++ b/include/hw/i386/apic-msidef.h
>> @@ -26,6 +26,7 @@
>>
>> #define MSI_ADDR_DEST_ID_SHIFT 12
>> #define MSI_ADDR_DEST_IDX_SHIFT 4
>> -#d
Wei Liu writes ("[PATCH for-4.9] build: more adjustments to top-level Makefile
dependencies"):
> In the original code, top-level dist target unconditionally invokes
> dist target for tools/include, which is wrong when tools component is
> not enabled.
>
> Make dist-tools depend on dist-tools-publ
>>> On 19.05.17 at 11:52, wrote:
> I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
> yes I know - very old ;-), but the affected code hasn't much changed.
Well, at the very least I'd expect you to base your code on
4.4.4 plus the about 199 backports we've added there ove
flight 109585 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 45 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 109515
test-xtf-amd64-
Hi,
On 19/05/17 13:09, Ian Jackson wrote:
Wei Liu writes ("[PATCH for-4.9] build: more adjustments to top-level Makefile
dependencies"):
In the original code, top-level dist target unconditionally invokes
dist target for tools/include, which is wrong when tools component is
not enabled.
Make
Hi,
On 19/05/17 11:27, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
On 18.05.17 at 17:38, wrote:
Modify Config.mk and Kconfig.debug to disable debug by default in
preparation for late RCs and eventual release.
Signed-off-by: Julien Grall
To avoid
>>> On 27.04.17 at 16:35, wrote:
> @@ -1048,6 +1050,24 @@ static int __init pvh_setup_acpi(struct domain *d,
> paddr_t start_info)
> return 0;
> }
>
> +int __init pvh_setup_ecam(struct domain *d)
While I won't object to the term ecam in title and description,
please use mmcfg uniformly i
Hi Ian,
On 18/05/17 19:11, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes"):
On 17/05/17 15:02, Julien Grall wrote:
For the last patch, at this stage of the release I would prefer to defer
it for Xen 4.10.
After reviewing these, I'd like to make a ca
>>> On 27.04.17 at 16:35, wrote:
> And also allow it to do non-identity mappings by adding a new parameter. This
> function will be needed in other parts apart from PVH Dom0 build. While there
> fix the function to use gfn_t and mfn_t instead of unsigned long for memory
> addresses.
I'm afraid bo
On Fri, May 19, 2017 at 02:23:42PM +0100, Julien Grall wrote:
> Hi,
>
> On 19/05/17 11:27, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> > > On 18.05.17 at 17:38, wrote:
> > > > Modify Config.mk and Kconfig.debug to disable debug by default in
> > >
Hi Andrew,
On 18/05/17 16:02, Andrew Cooper wrote:
On 18/05/17 15:31, Tim Deegan wrote:
Hi,
At 15:02 +0100 on 18 May (1495119734), Andrew Cooper wrote:
* When fabricating gl1e's from superpages, propagate the protection key as
well, so the protection key logic sees the real key as opposed
On 18/05/17 11:19, Andrew Cooper wrote:
On 16/05/17 11:16, Jan Beulich wrote:
First of all limit the memory range used for testing to 4Mb: There's no
point placing page tables right above 8Mb when they can equally well
live at the bottom of the chunk at 4Mb - rep_io_test() cares about the
5Mb.
>>> On 27.04.17 at 16:35, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -588,6 +588,51 @@ static void pci_enable_acs(struct pci_dev *pdev)
> pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
> }
>
> +int pci_size_bar(unsigned int seg
Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> Regarding the branching, I was thinking to branch right after the next
> RC. Any opinions on this?
That would be fine by me. We would want staging==master at the time
we branch, so we should have a commit moratorium too.
Ian
On 19/05/17 14:58, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
Regarding the branching, I was thinking to branch right after the next
RC. Any opinions on this?
That would be fine by me. We would want staging==master at the time
we branch, so we sh
On 19/05/17 14:20, osstest service owner wrote:
> flight 109585 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109585/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 45 xtf/tes
On Thu, May 18, 2017 at 08:07:00PM +0100, Andrew Cooper wrote:
> I would ask however how confident we are that there are no ELF parsing
> bugs in the code? I think it might be very prudent to try and build a
> userspace harness for it and let ALF have a go.
>
There is already a fuzzing harness i
On 19/05/17 15:32, Wei Liu wrote:
> On Thu, May 18, 2017 at 08:07:00PM +0100, Andrew Cooper wrote:
>> I would ask however how confident we are that there are no ELF parsing
>> bugs in the code? I think it might be very prudent to try and build a
>> userspace harness for it and let ALF have a go.
>
Andrew Cooper writes ("Re: [Xen-devel] [xen-4.8-testing test] 109585:
regressions - FAIL"):
> These are not actual regressions.
>
> test-hvm64-lbr-tsx-vmentry is generic test which runs on all hardware,
> but it triggers a host-specific failure mode on Intel Haswell processors
> and later.
...
>
Andrew Cooper writes ("Re: [Xen-devel] Livepatching and Xen Security"):
> livepatching doesn't use libelf.
>
> It is a new ELF parsing implementation.
I don't think we care very much about bugs in the livepatching elf
parser. The livepatches are all completely trusted in any case.
Furthermore,
Hi all,
Xen tree is going to branch at 4.9 RC6. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another announcement will be made
when the moratorium is lifted.
Cheers,
--
Julien Grall
___
>>> On 27.04.17 at 16:35, wrote:
> +static int vpci_modify_bars(struct pci_dev *pdev, const bool map)
> +{
> +struct vpci_header *header = &pdev->vpci->header;
> +unsigned int i;
> +int rc = 0;
> +
> +for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
> +{
> +paddr_t gadd
paravirt_disable_iospace() isn't used anywhere. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 2 --
arch/x86/kernel/paravirt.c| 19 ---
2 files changed, 21 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_irq_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h| 44 +++--
Move members needed for fully paravirtualized guests only into a new
structure pvfull_info in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/boot/compressed/misc.h | 1 +
arch/x86/include/asm/paravirt.
As arch/x86/xen/irq.c is used for pv-guests only, there is no need to
have a test targeting a HVM guest in it. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/xen/irq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 33e92
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_mmu_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
.flush_tlb_others is left in pv_mmu_ops as hyperv support will use it
soon.
Signed-off-by: Juergen Gross
---
Add a new config item PARAVIRT_FULL. It will be used to guard the
pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests
and lguest) only.
Kernels not meant to support those guest types will be able to use many
operations without paravirt abstraction while still supporting all the
paravirt_alloc_pmd_clone() doesn't exist anywhere. Remove its
prototype.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/pgalloc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index b2d0cd8288aa..71de65bb1791 100644
--
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_cpu_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_64.S | 4 +-
arch/x86/include/asm/deb
As there are now only very few pvops functions left when
CONFIG_PARAVIRT_FULL isn't set, merge the related structures into
one named "pv_ops".
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 32
arch/x86/include/asm/paravirt_types.h | 27
There is no need to include pv-guest only object files in a kernel not
configured to support those. Move Xen's irq.o, xen-asm*.o and pv parts
of entry_*.o into CONFIG_XEN_PV sections.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_32.S | 4 +++-
arch/x86/entry/entry_64.S | 6 --
arch/
Today paravirtualization is a all-or-nothing game: either a kernel is
compiled with no paravirtualization support at all, or it is supporting
paravirtualized environments like Xen pv-guests or lguest additionally
to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen
HVM-guests.
As support
Signed-off-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
xen/common/page_alloc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b365305..e744d81 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2292,6 +2292,
Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's PAGE_SCRUB_ABORT bit. The scrubber checks
Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.
Signed-off-by: Boris Ostrovsky
---
Changes in v4:
* Don't (debug-)scrub (and don't check for poison) before bootscrub completes
* Adjust scrub pattern
xen/Kconfig.de
. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
We keep track of the first unscrubbed page in a page buddy using first_dirty
field. For now it can have two values, 0 (whole buddy needs scrubbing) or
INVALID_DIRTY_IDX (the buddy does
Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.
Signed-off-by: Boris Ostrovsky
---
Changes in v4:
* Be careful with tasklets in idle_loop()
* Use per-cpu mapcache override
* Update node_to_scrub() algorithm to select clos
Changes in V4:
* Keep track of dirty pages in a buddy with page_info.u.free.first_dirty.
* Drop patch 1 (factoring out merge_and_free_buddy()) since there is only
one caller now
* Drop patch patch 5 (from V3) since we are not breaking partially-scrubbed
buddy anymore
* Extract search loop in al
While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.
Specifically, this feature will be needed by scrubbing code where
the scrubber,
When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.
Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_page
This will make code a bit more readable, especially with changes that
will be introduced in subsequent patches.
Signed-off-by: Boris Ostrovsky
---
Change in v4:
* New patch
xen/common/page_alloc.c | 132 +++-
1 file changed, 74 insertions(+), 58 delet
flight 109608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109608/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da0df6ca8f8f118866e53c7fb770598c13a6
baseline version:
ovmf f78c8bf2c64f57d5148be
flight 109619 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109619/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
The same set of functions is used to set as well as to clean P2M
entries, except for clean operations (INVALID_MFN ~0UL) is passed as a
parameter. Unfortunately, when calculating an appropriate target order
for a particular mapping INVALID_MFN is taken into account which leads
to 4K page target ord
flight 109586 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 3 host-install(3)broken REGR. vs. 109490
test-xtf-amd64-
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.12b-rc2-tag
xen: fixes for 4.12 rc2
It contains some fixes for the new Xen 9pfs frontend and some minor cleanups.
Thanks.
Juergen
arch/x86/xen/enlighten_pv.c | 15 ++-
arch/x
Hello Sameer,
On 19/05/17 07:38, Goel, Sameer wrote:
On 12/29/2016 7:04 AM, Julien Grall wrote:
### Finding the StreamID and DeviceID
The static table IORT (see [5]) will provide information that will help to
deduce the StreamID and DeviceID from a given RID.
IORT table will also need s
2017-05-17 2:16 GMT+08:00 Stefano Stabellini :
> On Tue, 16 May 2017, Jan Beulich wrote:
>> >>> On 15.05.17 at 19:40, wrote:
>> > On Mon, 15 May 2017, Jan Beulich wrote:
>> >> >>> On 15.05.17 at 12:21, wrote:
>> >> > On Zhongze proposal, the share page will be mapped at the a specific
>> >> > add
Hi, Wei,
2017-05-19 17:33 GMT+08:00 Wei Liu :
> On Thu, May 18, 2017 at 11:09:40AM -0700, Stefano Stabellini wrote:
>> > >
>> > > Yes, those attributes are necessary and should be explicitly specified
>> > > in the
>> > > config file. I'll add them in the next version of this proposal. And
>
On Sat, 20 May 2017, Zhongze Liu wrote:
> Hi, Wei,
>
> 2017-05-19 17:33 GMT+08:00 Wei Liu :
> > On Thu, May 18, 2017 at 11:09:40AM -0700, Stefano Stabellini wrote:
> >> > >
> >> > > Yes, those attributes are necessary and should be explicitly specified
> >> > > in the
> >> > > config file. I'
On Fri, 19 May 2017, Julien Grall wrote:
> The same set of functions is used to set as well as to clean P2M
> entries, except for clean operations (INVALID_MFN ~0UL) is passed as a
> parameter. Unfortunately, when calculating an appropriate target order
> for a particular mapping INVALID_MFN is tak
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: Friday, May 19, 2017 1:47 PM
> To: Zhongze Liu
> Cc: Wei Liu ; Stefano Stabellini
> ; xen-de...@lists.xenproject.org; Julien Grall
> ; Ian Jackson ; Jarvis
> Roach ; edg...@xilinx.com
> Subject: Re: Pro
From: Borislav Petkov
We use sync_core() in the alternatives code to stop speculative
execution of prefetched instructions because we are potentially changing
them and don't want to execute stale bytes.
What it does on most machines is call CPUID which is a serializing
instruction. And that's ex
As identified in Linux c/s c198b121b1a1d "x86/asm: Rewrite sync_core() to use
IRET-to-self", sync_core() is only appropriate for two very specific usecases.
Xen doesn't have need of either of these usecases, so drop sync_core() to
avoid any misuse.
In the unlikely event that we do gain a legitima
On Fri, 19 May 2017, Jarvis Roach wrote:
> > While waiting for Jarvis and Edgar to provide more befitting information,
> > I'll
> > try to fill in myself. There is a demand to run "bare-metal" applications on
> > embedded boards (such as the new Xilinx Zynq MPSoC board). People in
> > those commun
This run is configured for baseline tests only.
flight 71359 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71359/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
This run is configured for baseline tests only.
flight 71354 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 wind
flight 109621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Hi Stefano,
On 18 May 2017 at 22:00, Stefano Stabellini wrote:
> Description of the problem: need for a place to run emulators and
> mediators outside of Xen, with low latency.
>
> Explanation of what EL0 apps are. What should be their interface with
> Xen? Could the interface be the regular hyp
On Fri, May 19, 2017 at 11:17:24AM +0200, Jiri Slaby wrote:
> On 05/17/2017, 03:23 PM, Jiri Slaby wrote:
> >> So the initial CFI state is different between the two types of
> >> "functions". And there are a lot of other differences. C-type
> >> functions have to follow frame pointer conventions,
flight 109593 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
This run is configured for baseline tests only.
flight 71372 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71372/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109624/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Thu, 18 May 2017, Stefano Stabellini wrote:
> On Wed, 17 May 2017, Juergen Gross wrote:
> > On 16/05/17 21:58, Stefano Stabellini wrote:
> > > On Tue, 16 May 2017, Juergen Gross wrote:
> > >> On 15/05/17 22:35, Stefano Stabellini wrote:
> > >>> The pvcalls backend has one ioworker per cpu: the i
Hi all,
this series introduces the backend 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
sends POSIX function calls to the backend, which implements them an
Introduce the code to handle xenbus state changes.
Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.
Introduce stub functions for disconnecting/connecting to a frontend.
Signed-off
Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 29 -
1 file changed, 28 insertion
Introduce a per-frontend data structure named pvcalls_back_priv. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, accept and poll commands, while active
sockets only on re
Implement backend_disconnect. Call pvcalls_back_release_active on active
sockets and pvcalls_back_release_passive on passive sockets.
Implement module_exit by calling backend_disconnect on frontend
connections.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
Release both active and passive sockets. For active sockets, make sure
to avoid possible conflicts with the ioworker reading/writing to those
sockets concurrently. Set map->release to let the ioworker know
atomically that the socket will be released soon, then wait until the
ioworker finishes (flus
Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Allocate a workqueue and a work_struct, called ioworker, to perform
reads and write
Keep a list of connected frontends. Use a semaphore to protect list
accesses.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/xen/pvcalls-back.c
When an active socket has data available, increment the io and read
counters, and schedule the ioworker.
Implement the read function by reading from the socket, writing the data
to the data ring.
Set in_error on error.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@
Introduce the C header file which defines the PV Calls interface. It is
imported from xen/include/public/io/pvcalls.h.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/pvcalls.h | 120
We have one ioworker per socket. Each ioworker goes through the list of
outstanding read/write requests. Once all requests have been dealt with,
it returns.
We use one atomic counter per socket for "read" operations and one
for "write" operations to keep track of the reads/writes to do.
We also u
When the other end notifies us that there is data to be written
(pvcalls_back_conn_event), increment the io and write counters, and
schedule the ioworker.
Implement the write function called by ioworker by reading the data from
the data ring, writing it to the socket by calling inet_sendmsg.
Set
1 - 100 of 115 matches
Mail list logo
