I'm also working on a similar thing - can you please tell me how you copy
the memory pages from one part of the memory to another?
On Tue, Oct 13, 2015 at 10:04 AM 高强 wrote:
> Hi,alls
>
> I'm modifying the source code of xen-4.4.1. Specifically, I'm modifying
> the memory copy part of snapshot.
Jan Beulich wrote on 2015-10-12:
On 10.10.15 at 08:30, wrote:
>> Jan Beulich wrote on 2015-09-29:
>>> --- a/xen/drivers/passthrough/vtd/intremap.c
>>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>>> @@ -143,7 +143,7 @@ static void set_hpet_source_id(unsigned
>>> set_ire_sid(ire, SVT_VER
Jan Beulich wrote on 2015-10-12:
On 12.10.15 at 03:42, wrote:
>> According the discussion and suggestion you made in past several
>> weeks, obviously, it is not an easy task. So I am wondering whether
>> it is worth to do it since:
>> 1. ATS device is not popular. I only know one NIC from Myr
On 10/12/2015 09:46 PM, George Dunlap wrote:
On 12/10/15 08:19, Chun Yan Liu wrote:
+
+usbinfo->devnum = usb->u.hostdev.hostaddr;
+usbinfo->busnum = usb->u.hostdev.hostbus;
+
+busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
+ usb->u.hostdev.
Hi,alls
I'm modifying the source code of xen-4.4.1. Specifically, I'm modifying the
memory copy part of snapshot. I first put all memory pages to write
protection, and then rewrite the write protection exception part of the
code. After capture the exception then save the memory page , and all
mem
flight 62934 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62934/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 62795
test-armhf-ar
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, October 12, 2015 6:48 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
>
> On Mon, 2015-10-12 at 10:23
flight 62933 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 62780
test-amd64-amd64-xl-pv
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 12, 2015 6:42 PM
> To: Wu, Feng; xen-devel@lists.xen.org
> Cc: Tian, Kevin; Zhang, Yang Z; Jan Beulich; Keir Fraser; George Dunlap
> Subject: Re: [PATCH v8 01/17] VT-d Posted-intterrupt (
This run is configured for baseline tests only.
flight 38159 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38159/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-c
This run is configured for baseline tests only.
flight 38160 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38160/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf af9785a9ed61daea52b47f0bf448f1f228beee1e
baseline version:
ovm
flight 62939 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62939/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
flight 62908 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 59254
Hi All,
I noticed that DOM0 kernel fails to get time via RTC device on AMD ARM64
(Seattle) platform. On this platform Linux uses rtc-efi driver to get the time
through EFI runtime services, and I know for sure that driver works well
outside the Xen environment. It seems that devicetree passed t
On 06/10/15 11:06, Roger Pau Monné wrote:
> El 06/10/15 a les 11.58, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 06/10/2015 10:39, Roger Pau Monné wrote:
>>> El 05/10/15 a les 19.05, Julien Grall ha escrit:
On 05/10/15 17:01, Roger Pau Monné wrote:
> El 11/09/15 a les 21.32, Julien Grall
Hi all
We've had two separate discussions about release cycles, one for
normal release [0], the other for changes in stable release
maintenance and possible long term supported releases [1]. There were
overwhelming support for having a shorter release cycle from
xen-unstable but we couldn't reach
Signed-off-by: Stefano Stabellini
diff --git a/components/ovmf b/components/ovmf
index ffdde19..d2ed96c 100644
--- a/components/ovmf
+++ b/components/ovmf
@@ -1,7 +1,7 @@
#!/usr/bin/env bash
function ovmf_skip() {
-if [[ $RAISIN_ARCH != "x86_64" && $RAISIN_ARCH != "x86_32" ]]
+if [[
flight 62929 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62929/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf af9785a9ed61daea52b47f0bf448f1f228beee1e
baseline version:
ovmf 8145b63e975f86fad6ae09185cd228415b0
Signed-off-by: Wei Liu
---
.gitignore | 9 +
1 file changed, 9 insertions(+)
diff --git a/.gitignore b/.gitignore
index 35a46c6..8d7f100 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,15 @@ grub-dir
grub-dir-remote
libvirt-dir
libvirt-dir-remote
+ovmf-dir
+ovmf-dir-remote/
+qem
Hi all,
This small patch series allow Xen to boot on platform where the firmware
is only supporting PSCI v1.0.
Sincerely yours,
Julien Grall (2):
xen/arm: Add support of PSCI v1.0 for the host
xen/arm: Replace XEN_PSCI_* by PSCI_VERSION(major, minor)
xen/arch/arm/psci.c| 23 +++
It will avoid to introduce a new XEN_PSCI_* define every time we support
a new version of PSCI in Xen.
Also fix the coding style in modified place.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
---
xen/arch/arm/psci.c| 6 +++---
>From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
SYSTEM_RESET) behaves exactly the same.
Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version must be
compatible with 1.x when y > x for any functi
flight 62871 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62871/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62315
Tests which did not succeed, but a
flight 62835 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 9 windows-installfail REGR. vs. 62711
test-amd64-amd64-xl-
This run is configured for baseline tests only.
flight 38157 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumpuserxen-amd64 1 build-check(1)
As a consequence of commit 49388f11d512bb92706ce
("x86/cpufreq: relocate the driver register function")
the cpufreq CPU notifier was being registered twice.
That resulted in bugs when trying to offline a
CPU, as reported here:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg41618.html
Si
flight 38158 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38158/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail like 38123
test-amd64-amd64-i3
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3)
use 32-bit access and will crash at boot time.
Major changes in v4:
- Patch #1-#6 of the previous version has been applied
- Split "Opt
The current implementation ignores the whole write if one of the field is
0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
when:
- The interrupt is not wired in the distributor. From the Xen
point of view, it means that the corresponding bit is not set in
d->arch.
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.
While the target vCPU of an vIRQ is ret
During a store, the byte is always in the low part of the register (i.e
[0:7]).
Although, we are masking the register by using a shift of the
byte offset in the ITARGETSR. This will result to get a target list
equal to 0 which is ignored by the emulation.
Because of that a guest won't be able to
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
> If no one else is working on it, I'm going to start the next steps which is:
> * Load the ELF binary into Xen memory.
> * Resolve symbols.
> * Perform ELF relocations
I updated the Wiki xSplice with this and the URL to the tool.
>
> I'll use Konrad's xsplice.v1.1 branch as a starting point to p
On 12/10/15 08:19, Chun Yan Liu wrote:
>>> +
>>> +usbinfo->devnum = usb->u.hostdev.hostaddr;
>>> +usbinfo->busnum = usb->u.hostdev.hostbus;
>>> +
>>> +busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
>>> + usb->u.hostdev.hostaddr);
>>> +
On Mon, 2015-10-12 at 07:22 -0600, Jan Beulich wrote:
> > > > On 10.10.15 at 03:38, wrote:
> > On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
> > Please also remove "register_cpu_notifier(&cpu_nfb)" in the
> > cpufreq_register_driver function as well. (found that it has
> > already been
> >
>>> On 12.10.15 at 15:25, wrote:
> On 12/10/15 14:19, Jan Beulich wrote:
> On 09.10.15 at 22:00, wrote:
>>> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
>>> '__init' If you remove that little thing would it work?
>> Before adding this annotation I carefully chec
On 12/10/15 14:19, Jan Beulich wrote:
On 09.10.15 at 22:00, wrote:
>> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
>> '__init' If you remove that little thing would it work?
> Before adding this annotation I carefully check all callers, and both
> which I could
On Mon, 2015-10-12 at 07:19 -0600, Jan Beulich wrote:
> > > > On 09.10.15 at 22:00, wrote:
> > Anyhow it may be due to the fact that cpufreq_register_driver in
> > Xen is now
> > '__init' If you remove that little thing would it work?
>
> Before adding this annotation I carefully check all caller
>>> On 10.10.15 at 03:38, wrote:
> On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
>> > Hey,
>> >
>> > As far as my bisection goes, commit
>> > 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
>> > driver regis
>>> On 09.10.15 at 22:00, wrote:
> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
> '__init' If you remove that little thing would it work?
Before adding this annotation I carefully check all callers, and both
which I could find are themselves __init. Did I overlook a
On Mon, Oct 12, 2015 at 12:44:12PM +0100, Ross Lagerwall wrote:
> On 10/05/2015 11:28 AM, Ross Lagerwall wrote:
> >On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
> >>+### Generation of xSplice ELF payloads
> >>+
> >>+The design of that is not discussed in this design.
> >>+
> >>+The author of
On 12/10/15 13:56, Ben Hutchings wrote:
> On Mon, 2015-10-12 at 11:11 +0100, David Vrabel wrote:
>> On 08/10/15 23:14, Ben Hutchings wrote:
>>> On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
[resending to correct stable address, sorry folks]
TL;DR: Any backport of 30b03d05e07
On Mon, 2015-10-12 at 11:11 +0100, David Vrabel wrote:
> On 08/10/15 23:14, Ben Hutchings wrote:
> > On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
> > > [resending to correct stable address, sorry folks]
> > >
> > > TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
>
On Mon, 12 Oct 2015, Paolo Bonzini wrote:
> On 12/10/2015 13:09, Stefano Stabellini wrote:
> > On Sun, 11 Oct 2015, Lan Tianyu wrote:
> >> From: >
> >>
> >> msix->mmio is added to XenPCIPassthroughState's object as property.
> >> object_finalize_child_property is called for XenPCIPassthroughState's
>>> On 12.10.15 at 03:42, wrote:
> According the discussion and suggestion you made in past several weeks,
> obviously, it is not an easy task. So I am wondering whether it is worth to
> do it since:
> 1. ATS device is not popular. I only know one NIC from Myricom has ATS
> capabilities.
> 2.
On Mon, 2015-10-12 at 12:18 +, osstest service owner wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-qemut-win7-amd64
> test windows-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware
>>> On 11.10.15 at 13:09, wrote:
> On 11.10.2015 at 2:25, wrote:
>> At 17:02 + on 07 Oct (1444237344), Xu, Quan wrote:
>> > Q2: how do you know when to drop them?
>> >- log (or something) when the IOMMU entry is removed/overwritten; and
>> >- drop the entry when the flush completes.
>
branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-qemut-win7-amd64
test windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemu
On 12/10/2015 13:09, Stefano Stabellini wrote:
> On Sun, 11 Oct 2015, Lan Tianyu wrote:
>> From: >
>>
>> msix->mmio is added to XenPCIPassthroughState's object as property.
>> object_finalize_child_property is called for XenPCIPassthroughState's
>> object, which calls object_property_del_all, whi
On 10/05/2015 11:28 AM, Ross Lagerwall wrote:
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+The author of this design envisions objdump and objcopy along
+with special GCC parameters (see abo
On 12/10/15 12:07, Stefano Stabellini wrote:
> On Mon, 12 Oct 2015, Julien Grall wrote:
>> On 12/10/15 11:41, Stefano Stabellini wrote:
>>> On Thu, 8 Oct 2015, Ian Campbell wrote:
> If the concern is the behavior is changed, I'm happy to rework this code
> to keep exactly the same behavior.
flight 62930 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62930/
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. 60684
build-i386
On Sun, 11 Oct 2015, Lan Tianyu wrote:
> From: >
>
> msix->mmio is added to XenPCIPassthroughState's object as property.
> object_finalize_child_property is called for XenPCIPassthroughState's
> object, which calls object_property_del_all, which is going to try to
> delete msix->mmio. object_final
On Mon, 12 Oct 2015, Julien Grall wrote:
> On 12/10/15 11:41, Stefano Stabellini wrote:
> > On Thu, 8 Oct 2015, Ian Campbell wrote:
> >>> If the concern is the behavior is changed, I'm happy to rework this code
> >>> to keep exactly the same behavior. I.e any 32-bit write containing
> >>> a 0 byte
On 12/10/15 11:41, Stefano Stabellini wrote:
> On Thu, 8 Oct 2015, Ian Campbell wrote:
>>> If the concern is the behavior is changed, I'm happy to rework this code
>>> to keep exactly the same behavior. I.e any 32-bit write containing
>>> a 0 byte will be ignored. This is not optimal but at least I
On Mon, 2015-10-12 at 10:23 +, Hu, Robert wrote:
(please can you trim your quotes)
> > Some other issue arises:
> 1. pax '-M norm', this option isn't support by my RHEL-distributed pax. Shall
> I
> simply omit it? or use '-t' substitute it? I tried the latter, seems working.
The purpose of
On Thu, 8 Oct 2015, Ian Campbell wrote:
> > If the concern is the behavior is changed, I'm happy to rework this code
> > to keep exactly the same behavior. I.e any 32-bit write containing
> > a 0 byte will be ignored. This is not optimal but at least I'm not
> > opening the pandora box of fixing ev
On 12/10/15 09:54, Feng Wu wrote:
> Add the design doc for VT-d PI.
>
> CC: Kevin Tian
> CC: Yang Zhang
> CC: Jan Beulich
> CC: Keir Fraser
> CC: Andrew Cooper
> CC: George Dunlap
> Signed-off-by: Feng Wu
> Reviewed-by: Kevin Tian
> Reviewed-by: Konrad Rzeszutek Wilk
> ---
> docs/misc/vtd
On Fri, 2015-10-09 at 18:13 +0100, Ian Jackson wrote:
> This is all mad.
No kidding!
It doesn't appear to be possible to call setsid() from a shell script
(other than by re-execing oneself), which is a shame.
I wonder at what point we should just rewrite the whole thing in Perl?
Anyway right now
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, October 12, 2015 6:03 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
>
> On Mon, 2015-10-12 at 09:3
On 09/10/15 19:13, Tamas K Lengyel wrote:
>
>
> On Fri, Oct 9, 2015 at 7:26 AM, Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 08/10/15 21:57, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/mm/mem_sharing.c
> b/xen/arch/x86/mm/mem_sharing.c
> > index a95e105.
This run is configured for baseline tests only.
flight 38156 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38156/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 8145b63e975f86fad6ae09185cd228415b07c7e7
baseline version:
ovm
flight 62831 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62831/
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 13 guest-localmigrate
fail REGR. vs. 62318
Regre
On 12/10/15 07:07, Shuai Ruan wrote:
> This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
> The reserved bits of eax/ebx/ecx/edx must be cleaned up
> when call cpuid(0dh) with leaf 1 or 2..63.
>
> According to the spec the following bits must be reserved:
> For leaf 1, bits 03-04/08-31 of ecx i
On 08/10/15 23:14, Ben Hutchings wrote:
> On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
>> [resending to correct stable address, sorry folks]
>>
>> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
>> ("xen/gntdev: convert priv->lock to a mutex", which was added in v4.
On 12/10/15 07:07, Shuai Ruan wrote:
> This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
> to perform the xsave_area switching so that xen itself
> can benefit from them when available.
>
> For xsaves/xrstors/xsavec only use compact format. Add format conversion
> support when perfor
On Mon, 2015-10-12 at 09:34 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Monday, October 12, 2015 4:57 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> >
> > Subject: Re: [OSSTEST PATCH v14 P
This run is configured for baseline tests only.
flight 38155 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 9 window
On 08/10/15 18:23, Andrew Cooper wrote:
> On 08/10/15 17:46, George Dunlap wrote:
>> On 08/10/15 16:20, Andrew Cooper wrote:
>>> On 08/10/15 15:58, George Dunlap wrote:
On 29/09/15 18:31, Andrew Cooper wrote:
> On 29/09/15 17:55, Dario Faggioli wrote:
>> The insert_vcpu() scheduler hoo
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, October 12, 2015 4:57 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
>
> On Mon, 2015-10-12 at 08:04
On 12/10/15 07:07, Shuai Ruan wrote:
> This patch add basic definitions/helpers which will be used in
> later patches.
>
> Signed-off-by: Shuai Ruan
> ---
> xen/arch/x86/xstate.c | 16
> xen/include/asm-x86/hvm/vcpu.h | 1 +
> xen/include/asm-x86/msr-index.h | 2 ++
>
On 11/10/15 15:41, Wei Liu wrote:
> In 16181cbb (tools: Honor Config.mk debug value, rather than setting our
> own), configure doesn't set debug variable anymore. There is, however,
> one place that was missed. The file config/Tools.mk.in was still
> expecting a @debug@ value from configure. After
Extend struct iremap_entry according to VT-d Posted-Interrupts Spec.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Feng Wu
Acked-by: Kevin Tian
---
v8:
- Make use of the __uint128_t member in struct iremap_entry when needed
v7:
- Add a __uint128_t member to the union in struct iremap_entry
v4
Enable VT-d Posted-Interrupts and add a command line
parameter for it.
CC: Jan Beulich
Signed-off-by: Feng Wu
Reviewed-by: Kevin Tian
Acked-by: Jan Beulich
---
v6:
- Change the default value to 'false' in xen-command-line.markdown
docs/misc/xen-command-line.markdown | 9 -
xen/driver
This patch includes the following aspects:
- Handling logic when vCPU is blocked:
* Add a global vector to wake up the blocked vCPU
when an interrupt is being posted to it (This part
was sugguested by Yang Zhang ).
* Define two per-cpu variables:
1. pi_blocked_vcpu:
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
This patch adds an API which is used to update the IRTE
for posted-interrupt when guest changes MSI/MSI-X information.
CC: Yang Zhang
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Jan Beulich
---
v8:
- Some minor adjustment
v7:
- Remov
Add the design doc for VT-d PI.
CC: Kevin Tian
CC: Yang Zhang
CC: Jan Beulich
CC: Keir Fraser
CC: Andrew Cooper
CC: George Dunlap
Signed-off-by: Feng Wu
Reviewed-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
docs/misc/vtd-pi.txt | 332 +
Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Andrew Cooper
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
v8:
- Coding style
v7:
- Coding style.
v3:
- Use
Add the utility to dump the posted format IRTE.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Feng Wu
---
v8:
- Coding style
v7:
- Remove the two stage loop
v6:
- Fix a typo
v4:
- Newly added
xen/drivers/passthrough/vtd/utils.c | 28 +---
1 file changed, 21 insertion
This patch initializes the VT-d Posted-interrupt Descriptor.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
v7:
- Add comments to function 'pi_desc_init' to clarify why we
update the poste
When a vCPU is running in Root mode and a notification event
has been injected to it. we need to set VCPU_KICK_SOFTIRQ for
the current cpu, so the pending interrupt in PIRR will be
synced to vIRR before VM-Exit in time.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-of
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
This patch adds variable 'iommu_intpost' to contr
Move some APIC related macros to apicdef.h, so they can be used
outside of vlapic.c.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Acked-by: Jan Beulich
---
v8:
- Minor changes
v7:
- Put the Macros to the right place inside the file.
v6:
- Newly introduced.
xen/
When guest changes its interrupt configuration (such as, vector, etc.)
for direct-assigned devices, we need to update the associated IRTE
with the new guest vector, so external interrupts from the assigned
devices can be injected to guests without VM-Exit.
For lowest-priority interrupts, we use ve
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Fe
Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Ja
Remove pointless casts.
CC: Yang Zhang
CC: Kevin Tian
Suggested-by: Jan Beulich
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
---
v7:
- Remove an 'u32' casting omitted in v5
v5:
- Newly added.
xen/drivers/passthrough/vtd/utils.c | 16 +++-
1 file changed, 7 insertio
This patch adds some helper functions to manipulate the
Posted-Interrupts Descriptor.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
---
v7:
- Use bitfield in pi_test_on() and pi_test_sn()
v4:
- Newly added
xen/in
This patch adds cmpxchg16b support for x86-64, so software
can perform 128-bit atomic write/read.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
---
v8:
- Remove pointless cast when assigning 'new_low'
- properly parenthesize cmpxchg16b()
v7:
- Make the last two para
On Mon, 2015-10-12 at 08:04 +, Hu, Robert wrote:
> > -Original Message-
> > From: Hu, Robert
> > Sent: Monday, October 12, 2015 11:36 AM
> > To: Ian Jackson ;
> > xen-de...@lists.xenproject.org
> > Cc: Ian Campbell
> > Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
On Mon, 2015-10-12 at 03:35 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson
> > Subject: [OSSTE
On Mon, 2015-10-12 at 03:04 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 12:36 AM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com;
> > wei.l...@citrix.com;
> > Ji
On Mon, 2015-10-12 at 07:42 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson
>
Seems I forgot to send this out last week, sorry.
The next Xen technical call will be at:
Wed 14 Oct 17:00:00 BST 2015
`date -d @1444838400`
See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html
for more information on the call.
Please let me know (CC-ing the list) any t
> -Original Message-
> From: Hu, Robert
> Sent: Monday, October 12, 2015 11:36 AM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
>
> > -Original Message-
> > From: Ian Jackson [mailto:ia
flight 62786 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684
test-amd64
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 18/26] LVM: Break out lv_create
>
> We ar
>>> On 10/1/2015 at 01:55 AM, in message <560c2204.9030...@citrix.com>, George
Dunlap wrote:
> On 25/09/15 03:11, Chunyan Liu wrote:
> > Add pvusb APIs, including:
> > - attach/detach (create/destroy) virtual usb controller.
> > - attach/detach usb device
> > - list usb controllers and u
1 - 100 of 104 matches
Mail list logo
