>>> 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_VERIFY_SID_SQ, SQ_13_IGNORE_3,
>> hpetid_t
>>> On 10/8/2015 at 10:41 PM, in message
<22038.32910.375958.407...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Chunyan Liu writes ("[PATCH V7 3/7] libxl: add pvusb API"):
> > Add pvusb APIs, including:
> ...
>
> > +/* Utility to read backend xenstore keys */
> > +#define READ_BACKEND
>>> On 10.10.15 at 10:22, wrote:
>> > >>> On 29.09.2015 at 16:57 wrote:
>> >>> On 16.09.15 at 15:23, wrote:
>> > +/* IOMMU Queued Invalidation(QI). */
>> > +static void _qi_msi_unmask(struct iommu *iommu) {
>> > +u32 sts;
>> > +unsigned long flags;
>> > +
>> > +/* Clear IM bit of DMA
>>> On 10.10.15 at 14:27, wrote:
>> > >>> On 29.09.2015 at 17:24 wrote:
>> >>> On 16.09.15 at 15:23, wrote:
>> > +qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(
>> > +
>> &qi_table_pollslot(d)) >> 2;
>> > +rcu_unlock_domain(d);
>>
>> If you don't hold a reference to the
>>> 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
> -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
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: 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
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
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
>
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 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 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
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
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
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
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
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 +
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:
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
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
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
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
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
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 ++
>
> -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 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
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 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
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 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 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
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
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
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.
> -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 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
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 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 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 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, 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 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
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 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.
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/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
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 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.
>
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 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, 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 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 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, 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 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 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 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 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 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 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 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);
>>> +
> 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
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
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
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
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
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
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
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)
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-
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
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
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 +++
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
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: 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 [[
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
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,
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
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
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
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
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
> -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 (
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: 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 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
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
1 - 100 of 104 matches
Mail list logo
