flight 112896 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112896/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
112809
test-amd64-
flight 112899 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112899/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 714c2603018a99a514c42c2b511c821f30ba9cdf
baseline version:
ovmf 9f3a38cdfb354a5a07431
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, August 25, 2017 9:59 PM
>
> On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote:
> > >>> On 25.08.17 at 14:15, wrote:
> > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote:
> > >> >>> On 22.08.17 at 15:54,
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 23, 2017 4:19 PM
> To: Roger Pau Monne
> Cc: Tian, Kevin ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH
> implementation of iommu_inclusive_mapping
>
> >>> On 22.08.17 at
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Thursday, August 17, 2017 5:39 PM
>
> > >
> > > +void __hwdom_init vtd_set_pvh_hwdom_mapping(struct domain *d)
> > > +{
> > > +unsigned long pfn;
> > > +
> > > +BUG_ON(!is_hardware_domain(d));
> > > +
> > > +if ( !iommu_incl
find_next_rmrr(base) is used to find the lowest RMRR ending above base
but below 4G. Current method couldn't cover the following situation:
a. two rmrr exist, small gap between them
b. pci_mem_start and mem_resource.base is below the first rmrr.base
c. find_next_rmrr(pci_mem_start) will find the fi
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Thursday, August 17, 2017 5:35 PM
>
> On Thu, Aug 17, 2017 at 03:12:45AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, August 12, 2017 12:43 AM
> > >
> > > This is emulated by Xen and must not be mapped int
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Thursday, August 17, 2017 5:32 PM
>
> On Thu, Aug 17, 2017 at 03:12:02AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, August 12, 2017 12:43 AM
> > >
> > > They are emulated by Xen, so they must not be mapp
> From: Gao, Chao
> Sent: Monday, August 28, 2017 10:42 AM
>
> When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
> are under the scope of the same VT-d unit as the 'Physical Function'.
> A 'Physical Function' can be a 'Traditional Function' or an ARI
> 'Extended Function'. And f
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, August 25, 2017 11:20 PM
>
>
> > Currently, VF won't implement SRIOV feature, seeing
> > SRIOV specv1.1 chapter 3.7 PCI Express Extended Capabilities. Even VF
> > will implement SRIOV later, I think as long as a function is SRIOV
> >
Hi,
Follow Juergen's advice, +CC xen-devel and linux-acpi
In case a single patch of a series isn't stand alone it would be nice
to receive at least the cover letter of the series in order to know
what its all about.
Thanks,
dou.
At 08/28/2017 11:20 AM, Dou Liyang wrote:
Changes V7 -->
Hi all,
Today's linux-next merge of the xen-tip tree got conflicts in:
arch/x86/xen/xen-asm.S
arch/x86/xen/xen-asm_64.S
between commit:
edcb5cf84f05 ("x86/paravirt/xen: Remove xen_patch()")
from the tip tree and commits:
ad5b8c4ba323("xen: get rid of paravirt op adjust_exception_frame
Hi Juergen,
At 08/28/2017 12:32 PM, Juergen Gross wrote:
On 28/08/17 06:25, Juergen Gross wrote:
On 28/08/17 05:20, Dou Liyang wrote:
XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
initializes interrupts in the XEN PV specific way and does not invoke
native_smp_prepare_cpus().
On 28/08/17 06:25, Juergen Gross wrote:
> On 28/08/17 05:20, Dou Liyang wrote:
>> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
>> initializes interrupts in the XEN PV specific way and does not invoke
>> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
>> n
On 28/08/17 05:20, Dou Liyang wrote:
> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
> initializes interrupts in the XEN PV specific way and does not invoke
> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
> not invoked either.
>
> The invocation of x86_
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
are under the scope of the same VT-d unit as the 'Physical Function'.
A 'Physical Function' can be a 'Traditional Function' or an ARI
'Extended Function'. And furthermore, 'Extended Functions' on an
endpoint are under the scope of
XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
initializes interrupts in the XEN PV specific way and does not invoke
native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
not invoked either.
The invocation of x86_init.intr_mode_init() will be moved from
native_s
flight 112895 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112891
Regressions which a
On 08/21/17 07:31, Peter Zijlstra wrote:
> On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>
>>> Have you considered a kernel with -mcmodel=small (or medium) instead of
>>> -fpie
>>> -mcmodel=large? We can pick a random 2GB
flight 112894 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112894/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
On Fri, Aug 25, 2017 at 11:38 AM, Christopher Lameter wrote:
>
>
> On Thu, 17 Aug 2017, Boris Lukashev wrote:
>
>> Is the expectation then to have security functions also decrease size
>> and operational latency? Seems a bit unrealistic if so.
>> 1-2% performance hit on systems which have become a
flight 112893 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
112809
test-amd64-
flight 112891 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112891/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112887
pass in 112891
test-amd64-i386-xl-
flight 112889 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112889/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
flight 112890 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112890/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
flight 112888 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112809
test-amd64-
flight 112892 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112892/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 803c5a2a42e7c72a4c848e0f0106a941b758a91f
baseline version:
xen 4a04
The original dummy xsm_map_gmfn_foregin checks if source domain has the proper
privileges over the target domain. Under this policy, it's not allowed if a Dom0
wants to map pages from one DomU to another, which restricts some useful yet not
dangerous use cases of the API, such as sharing pages amon
Add a new structure to the IDL familiy to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
Also fix some code style issues (indentation, trailling whitespaces).
[1] https://lists.xen.org/archives/h
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_p
This series implements the new xl config entry proposed in [1]. Users can use
the new config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each other
through the static shared memory areas.
[1] Proposla to allow sett
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a master: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a slave: unmap the shared pages, and cleanup
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).
[1] https:/
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the follwing steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
no master domain etc.
* Write infomatio
flight 112887 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112876
test-amd64-i3
Hi,
I'm updating this document to reflect some changes in the code based on the
discussions on #xen-devel and on the mailing list.
The biggest change is to ref-counting the sshm xenstore entry to avoid removing
the node too early while the memory pages are still in use, in section 2.2.
The rest
36 matches
Mail list logo