>>> On 18.07.15 at 00:32, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Thursday, July 16, 2015 2:34 AM
>>
> On 16.07.15 at 11:16, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, July 14, 2015 7:32 AM
>>> On 14.07.15 at 02:14, wrote:
> @@
Hi, everyone.
I don't quite follow the design philosophy of blktap. Since every virtual
disk is backed by a tapdisk process, when there are hundreds of domU
running and doing I/O operation simultaneously, which means that hundreds
of tapdisk process are doing I/O read/write simulataneously in dom0
This patch parses to enable user configurable parameters to specify
RDM resource and according policies which are defined previously,
Global RDM parameter:
rdm = "strategy=host,policy=strict/relaxed"
Per-device RDM parameter:
pci = [ 'sbdf, rdm_policy=strict/relaxed' ]
Default per-device
From: Jan Beulich
This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.
CC: Jan Beulich
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Jan Beulich
Signed-off-by: Tiejun Chen
Acked-by: Kevin Tian
---
v
We will introduce the hypercall xc_reserved_device_memory_map
approach to libxc. This helps us get rdm entry info according to
different parameters. If flag == PCI_DEV_RDM_ALL, all entries
should be exposed. Or we just expose that rdm entry specific to
a SBDF.
CC: Ian Jackson
CC: Stefano Stabelli
RMRR reserved regions must be setup in the pfn space with an identity
mapping to reported mfn. However existing code has problem to setup
correct mapping when VT-d shares EPT page table, so lead to problem
when assigning devices (e.g GPU) with RMRR reported. So instead, this
patch aims to setup ide
Try to avoid placing PCI BARs over RMRRs:
- If mmio_hole_size is not specified, and the existing MMIO range has
RMRRs in it, and there is space to expand the hole in lowmem without
moving more memory, then make the MMIO hole as large as possible.
- When placing RMRRs, find the next RMRR highe
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist, and hvmloader would need this info
later.
Note this guest e820 table would be same as before if the
platform has no any RDM or we disable RDM (by default).
CC: Ian
This patch enables XENMEM_memory_map in hvm. So hvmloader can
use it to setup the e820 mappings.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Tiejun Chen
Reviewed-by: Tim Deegan
Reviewed-by: Kevin Tian
Acked-by: Jan Beulich
Acked-by: George Dunlap
---
v5 ~ v10:
* Nothi
Previously we always fix that predefined boundary as 2G to handle
conflict between memory and rdm, but now this predefined boundar
can be changes with the parameter "rdm_mem_boundary" in .cfg file.
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Acked-by: Wei Liu
Acked-by:
Now we get this map layout by call XENMEM_memory_map then
save them into one global variable memory_map[]. It should
include lowmem range, rdm range and highmem range. Note
rdm range and highmem range may not exist in some cases.
And here we need to check if any reserved memory conflicts with
[RES
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and high_mem_pgend. So we should
check them to fix any conflict with RDM.
RMRR can reside in address space beyond 4
This patch introduces user configurable parameters to specify RDM
resource and according policies,
Global RDM parameter:
rdm = "strategy=host,policy=strict/relaxed"
Per-device RDM parameter:
pci = [ 'sbdf, rdm_policy=strict/relaxed' ]
Global RDM parameter, "strategy", allows user to speci
Now use the hypervisor-supplied memory map to build our final e820 table:
* Add regions for BIOS ranges and other special mappings not in the
hypervisor map
* Add in the hypervisor supplied regions
* Adjust the lowmem and highmem regions if we've had to relocate
memory (adding a highmem region
This patch extends the existing hypercall to support rdm reservation policy.
We return error or just throw out a warning message depending on whether
the policy is "strict" or "relaxed" when reserving RDM regions in pfn space.
Note in some special cases, e.g. add a device to hwdomain, and remove a
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning devices to a VM.
Note this also bring some fallout to python usage of xc_assign_device().
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
CC: David Scott
Acked-by: Wei L
USB RMRR may conflict with guest BIOS region. In such case, identity
mapping setup is simply skipped in previous implementation. Now we
can handle this scenario cleanly with new policy mechanism so previous
hack code can be removed now.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Tiejun Chen
A
Currently we're intending to cover this kind of devices
with shared RMRR simply since the case of shared RMRR is
a rare case according to our previous experiences. But
late we can group these devices which shared rmrr, and
then allow all devices within a group to be assigned to
same domain.
CC: Ya
v10:
* Patch #6: hvmloader/pci: Try to avoid placing BARs in RMRRs
This is from George' draft patch which implements an acceptable
solution in current cycle. Here I just implemented check_overlap_all() and
some cleanups.
* Patch #7: hvmloader/e820: construct guest e820 table
Instead of co
>>> On 17.07.15 at 23:08, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Thursday, July 16, 2015 2:39 AM
>>
> On 16.07.15 at 11:20, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, July 14, 2015 6:57 AM
>>> On 14.07.15 at 02:14, wrote:
> +st
>>> On 18.07.15 at 00:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Thursday, July 16, 2015 2:08 AM
>>
> On 16.07.15 at 10:57, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, July 14, 2015 6:13 AM
>>> On 14.07.15 at 02:14, wrote:
> @@
Before you add memory_map.nr_map, you should be able to iterate
from 0 to (not inclusive) nr. At least as far as I recall the original
patch.
Sorry, I really don't understand what you want.
Before we add memory_map.nr_map, e820[0, nr) don't include low/high
memory, right?
Why? memory_map is
>>> On 18.07.15 at 00:39, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Thursday, July 16, 2015 2:02 AM
>>
> On 16.07.15 at 10:48, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, July 14, 2015 1:53 AM
>>> On 14.07.15 at 02:01, wrote:
>>Fro
flight 59758 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 30511
build-amd64-rumpuserxen
flight 59760 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59760/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 59059
build-i386-pvops
Ping?
On 06/23/2015 08:53 AM, Juergen Gross wrote:
This series adds XEN guest pvUSB support. With pvUSB it is possible to
use physical USB devices from a XEN domain.
The support consists of a frontend in form of a virtual hcd driver in
the unprivileged domU passing I/O-requests to the backend i
hi,all
I adjusted time back to year 1900 in windows guest vm. And when i
rebooted the vm, it failed.
It seems that the value of adjustment exceed the range. Any suggestions?
The logs:
[2015-06-26 11:13:13 15113] DEBUG (SrvDomain:76) Starting domain
instance-01bb False
[2015-06-26 11:13:
flight 59757 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 58581
build-i386-pvops
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, July 16, 2015 7:57 PM
>
> Several error paths would end up freeing scope->devices twice.
>
> Signed-off-by: Andrew Cooper
> CC: Jan Beulich
> CC: Elena Ufimtseva
> CC: Yang Zhang
> CC: Kevin Tian
Acked-by: Kevin Tian
> From: Ting-Wei Lan [mailto:lant...@gmail.com]
> Sent: Saturday, July 18, 2015 3:06 AM
>
> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> devices, It is possible to encounter graphics issues that make screen
> unreadable or crash the system. It was reported in freedesk
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, July 17, 2015 11:11 PM
>
> On 17/07/15 15:01, Wei Liu wrote:
> > On Fri, Jul 17, 2015 at 02:43:05PM +0100, Jan Beulich wrote:
> > On 17.07.15 at 15:21, wrote:
> >>> The major concern seems to be around the PCI allocation
> From: Chen, Tiejun
> Sent: Friday, July 17, 2015 8:45 AM
>
> This patch extends the existing hypercall to support rdm reservation policy.
> We return error or just throw out a warning message depending on whether
> the policy is "strict" or "relaxed" when reserving RDM regions in pfn space.
> No
flight 59746 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 58581
build-i386-pvops
flight 59744 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59744/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 30511
build-i386-pvops
flight 59736 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 58965
build-i386-pvops
flight 59726 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 59059
test-amd64-i386-fre
Hi,
On 17/07/2015 20:05, Ting-Wei Lan wrote:
When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
devices, It is possible to encounter graphics issues that make screen
unreadable or crash the system. It was reported in freedesktop bugzilla:
https://bugs.freedesktop.org/show_
flight 59734 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 58581
build-i386-pvops
flight 59735 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 30511
build-i386-pvops
flight 59729 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 3 host-install(3) broken REGR. vs. 59254
build-i386-xsm
flight 59721 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 58965
Tes
blktap2 fails to build with gcc5 because it fails to recognize that
there can be just one active connection (enforced in ctl_accept).
Rearrange the code to handle just a single connection.
Adjust two strerror calls to use errno instead -1 as input.
[ 198s] block-log.c: In function 'ctl_close_soc
flight 59718 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail in 59697 REGR. vs. 58581
Tests which are failin
flight 59730 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 58842
build-amd64-pvops
44 matches
Mail list logo
