Xen currently does not have PCI support for ARM builds. This patch set
makes the code compilable for ARM PCI and adds places-holder code
which would be replaced with PCI pass-through support patch series.
Re-factor MSI Handling
-
There is a some x86 specific code which is found in com
This patch re-factors msi specific code to x86 specific files from
xen/drivers/passthrough/pci.c.
Signed-off-by: Manish Jaggi
---
xen/drivers/passthrough/pci.c| 102 +-
xen/drivers/passthrough/x86/Makefile |1 +
xen/drivers/passthrough/x86/pci.c| 11
Add ARM PCI Support
---
a) Place holder functions are added for pci_conf_read/write calls.
b) Macros dev_is_pci, pci_to_dev are implemented in
drivers/passthrough/pci/arm code
Signed-off-by: Manish Jaggi
---
xen/arch/arm/Makefile|1 +
xen/arch/arm/pci.c
flight 50394 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 4 capture-logs!broken in 50358 [st=!broken!]
build-i386-rumpus
Hi all,
After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring':
drivers/char/tpm/xen-tpmfront.c:203:7: warning: passing argument 2 of
'xenbus_grant_ring' makes pointer from integer without a cast
HI
I have a question about Inject virq to Domain on Xen ARM.
Function 'vgic_vcpu_inject_irq' is inject virq to target vcpu.
At the end of vgic_vcpu_inject_irq, like below
--
running = v->is_running;
vcpu_unblock(v);
if ( running && v !=
>>> On 01.04.15 at 11:59, wrote:
> On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
>> On 01/04/15 10:20, Stefano Stabellini wrote:
>> > CC'ing the author of the patch and xen-devel.
>> > FYI I think that Jan is going to be on vacation for a couple of weeks.
>> >
>> > On Wed, 1 Apr 2
>>> On 02.04.15 at 12:01, wrote:
> On Thu, 2015-03-26 at 17:07 +, Jan Beulich wrote:
>> having been released mid January, it is time to get ready for 4.5.1-rc1.
>> Please reply with backport requests which you consider necessary but
>> still missing. Please also be patient with them being pull
>>> On 30.03.15 at 15:15, wrote:
> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>> All,
>>
>> having been released mid January, it is time to get ready for 4.5.1-rc1.
>> Please reply with backport requests which you consider necessary but
>> still missing. Please also be patient with them bein
Hi Stephen,
On 04/13/2015 04:09 PM, Stephen Rothwell wrote:
Hi all,
After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring':
drivers/char/tpm/xen-tpmfront.c:203:7: warning: passing argument 2 of
Hi David,
On 04/03/2015 03:22 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Apr 02, 2015 at 05:21:50PM +0100, David Vrabel wrote:
All,
Are there any outstanding patches that should be added to Linux 4.1
(the merge window for which will be opening shortly)?
Bob's two patches to the deferred grant
>>> On 02.04.15 at 11:45, wrote:
> On Wed, 2015-04-01 at 13:28 +, Olaf Hering wrote:
>> To allow reproducible builds of hvmloader introduce a make variable
>> VGABIOS_REL_DATE="dd Mon " to provide a fixed date string. Without
>> this change the hvmloader binary changes with every rebuild.
>>> On 10.04.15 at 22:02, wrote:
> On Wed, Mar 25, 2015 at 04:39:49PM +, Jan Beulich wrote:
>> As done in Linux by f598282f51 ("PCI: Fix the NIU MSI-X problem in a
>> better way") and its broken predecessor, make sure we don't access the
>> MSI-X table without having enabled MSI-X first, using
On 13/04/15 09:36, Jan Beulich wrote:
On 30.03.15 at 15:15, wrote:
>> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>>> All,
>>>
>>> having been released mid January, it is time to get ready for 4.5.1-rc1.
>>> Please reply with backport requests which you consider necessary but
>>> still mi
>>> On 02.04.15 at 18:49, wrote:
> On Wed, 25 Mar 2015, Jan Beulich wrote:
>> When a device gets detached from a guest, pciback will clear its
>> command register, thus disabling both memory and I/O decoding. The
>> disabled memory decoding, however, has an effect on the MSI-X table
>> accesses th
This patch set adds nested HVM test case for osstest.
In this test case, a Xen hypervisor (L1) runs on top of another Xen
hypervisor (L0).
Upon L1 hypervisor, we will then create a nested guest (L2), and test if the
Linux guest can then be installed and run well.
About nested Xen virtualization,
1. This patch adds creation of the nested test job, when job creation
procedure is invoked.
2. Set nested L1's vif model as e1000 by make-flight.
Signed-off-by: longtao.pang
---
Changes in v8:
1. Use 'nestedl1' and 'nestedl2' as L1 and L2's clearer name in nested
test job.
2. Setting Debian_ISO a
1. Increase disk size to accommodate to nested test requirement.
2. Since 'Debain-xxx-.iso' image will be stored in rootfs of L1 guest,
therefore needs more disk capacity, increase root partition size in
preseed generation.
3. In L1 installation context, assign more memory to it; Since it
acts as a
1. In this script, make some appropriate runvars which selecthost would
recognise.
2. Prepare the configurations for installing L2 guest VM.
3. Create a lv disk in L0 and hot-attach it to L1, need to restart L1 to
make the block disk to be recognized by L1 system, then using this disk
to create a V
Support situations of grub that have vmlinuz and other things starting
with path of '/boot' rather than '/'.
Signed-off-by: longtao.pang
---
Osstest/Debian.pm |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 378af54..1a57c
1. Designate vif model by make-flight.
2. In L2 installation context, its host (L1) IP address is not queried
from DNS, but after running "ts-nested-setup + host + nested", L1 IP is
stored in runvar.
Signed-off-by: longtao.pang
---
Changes in v8:
Remove the unnecessary symbol of ';' in 'TestSuppo
Signed-off-by: longtao.pang
---
Changes in v8:
Change the patch order from 6 to 5.
---
sg-run-job | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sg-run-job b/sg-run-job
index eae159d..2ca5ebf 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -299,6 +299,17 @@ proc run-job/test-pair
>From a hvm kernel build from Linux stable Kernel tree,
the auto generated grub2 menu will have 'submenu' primitive, upon the
'menuentry' items. Xen boot entries will be grouped into a submenu. This
patch adds capability to support such grub formats.
Signed-off-by: longtao.pang
---
Changes in v8:
Hi David,
I seem to have spotted some trouble with a 4.0 dom0 kernel with the
devel/for-linus-4.1 branch pulled on top.
Does this remind you of any specific commits in the devel/for-linus-4.1 branch
that could
likely be involved that i could try to revert ?
--
Sander
I now get a very large n
On 13/04/15 10:39, Sander Eikelenboom wrote:
> Hi David,
>
> I seem to have spotted some trouble with a 4.0 dom0 kernel with the
> devel/for-linus-4.1 branch pulled on top.
>
> Does this remind you of any specific commits in the devel/for-linus-4.1
> branch that could
> likely be involved that
On 02/04/15 20:22, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 02, 2015 at 05:21:50PM +0100, David Vrabel wrote:
>> All,
>>
>> Are there any outstanding patches that should be added to Linux 4.1
>> (the merge window for which will be opening shortly)?
>
> Bob's two patches to the deferred grant mec
On Mon, 13 Apr 2015, Manish Jaggi wrote:
> Add ARM PCI Support
> ---
> a) Place holder functions are added for pci_conf_read/write calls.
> b) Macros dev_is_pci, pci_to_dev are implemented in
> drivers/passthrough/pci/arm code
>
> Signed-off-by: Manish Jaggi
> ---
> xen/arch/arm/Make
On Mon, 13 Apr 2015, Manish Jaggi wrote:
> This patch re-factors msi specific code to x86 specific files from
> xen/drivers/passthrough/pci.c.
>
> Signed-off-by: Manish Jaggi
> ---
> xen/drivers/passthrough/pci.c| 102 +-
> xen/drivers/passthrough/x86/Makefil
Hi Manish,
On 13/04/15 08:37, Manish Jaggi wrote:
> Xen currently does not have PCI support for ARM builds. This patch set
> makes the code compilable for ARM PCI and adds places-holder code
> which would be replaced with PCI pass-through support patch series.
May I ask why you did send directly
On 04/10/2015 03:29 PM, Stefano Stabellini wrote:
>> diff --git a/raise b/raise
>> new file mode 100755
>> index 000..7f3faae
>> --- /dev/null
>> +++ b/raise
>> @@ -0,0 +1,16 @@
>> +#!/usr/bin/env bash
>
> It is important to "set -e" immediately to catch all possible errors:
>
> "-e Exit im
On Monday 13 April 2015 03:44 PM, Stefano Stabellini wrote:
On Mon, 13 Apr 2015, Manish Jaggi wrote:
Add ARM PCI Support
---
a) Place holder functions are added for pci_conf_read/write calls.
b) Macros dev_is_pci, pci_to_dev are implemented in
drivers/passthrough/pci/arm code
Signe
On Monday 13 April 2015 03:45 PM, Stefano Stabellini wrote:
On Mon, 13 Apr 2015, Manish Jaggi wrote:
This patch re-factors msi specific code to x86 specific files from
xen/drivers/passthrough/pci.c.
Signed-off-by: Manish Jaggi
---
xen/drivers/passthrough/pci.c| 102 +---
BTW, your series is not threaded.
I've already said it on another series. Please look at [1] to see how to
send correctly your series.
[1]
http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_the_patches_to_the_list
Regards,
On 13/04/15 11:19, Julien Grall wrote:
> Hi Manish,
Hi Manish,
On 13/04/15 08:40, Manish Jaggi wrote:
> -static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
> -{
> -struct pci_dev *pdev;
> -struct msi_desc *msi;
> -
> -printk(" segment %04x \n", pseg->nr);
> -
> -list_for_each_entry ( pdev, &pseg->alldevs_list, all
On 04/10/2015 03:29 PM, Stefano Stabellini wrote:
>> +arg_parse_cmd=\
>> +"local -a args;
>> +local _a;
>> +local _vn;
>> +local _m;
>> +
>> +_m=true;
>> +
>> +for _a in \"\$@\" ; do
>> +false && echo \"Evaluating \${_a} [[ \"\${_a/=}\" = \"\${_a}\" ]]\";
>> +if \$_m && [[ \"\${_a/=}\" != \
Hi Manish,
On 13/04/15 08:48, Manish Jaggi wrote:
> Add ARM PCI Support
> ---
> a) Place holder functions are added for pci_conf_read/write calls.
> b) Macros dev_is_pci, pci_to_dev are implemented in
> drivers/passthrough/pci/arm code
>
> Signed-off-by: Manish Jaggi
> ---
> xen/arc
>>> On 27.03.15 at 19:31, wrote:
> On 26/03/15 12:38, Chao Peng wrote:
>> +cpuid_count(PSR_CPUID_LEVEL_CAT, 0, &eax, &ebx, &ecx, &edx);
>> +if ( ebx & PSR_RESOURCE_TYPE_L3 )
>> +{
>> +cpuid_count(PSR_CPUID_LEVEL_CAT, 1, &eax, &ebx, &ecx, &edx);
>> +info->cbm_len = (eax
On Mon, 13 Apr 2015, Jan Beulich wrote:
> >>> On 02.04.15 at 18:49, wrote:
> > On Wed, 25 Mar 2015, Jan Beulich wrote:
> >> When a device gets detached from a guest, pciback will clear its
> >> command register, thus disabling both memory and I/O decoding. The
> >> disabled memory decoding, howeve
On Thu, Apr 9, 2015 at 5:36 PM, Stefano Stabellini
wrote:
> On Thu, 9 Apr 2015, Eric Dumazet wrote:
>> On Thu, 2015-04-09 at 16:46 +0100, Stefano Stabellini wrote:
>> > Hi all,
>> >
>> > I found a performance regression when running netperf -t TCP_MAERTS from
>> > an external host to a Xen VM on A
On 13/04/15 11:51, Jan Beulich wrote:
On 27.03.15 at 19:31, wrote:
>> On 26/03/15 12:38, Chao Peng wrote:
>>> +cpuid_count(PSR_CPUID_LEVEL_CAT, 0, &eax, &ebx, &ecx, &edx);
>>> +if ( ebx & PSR_RESOURCE_TYPE_L3 )
>>> +{
>>> +cpuid_count(PSR_CPUID_LEVEL_CAT, 1, &eax, &ebx, &e
On Mon, Apr 13, 2015 at 10:09:51AM +0800, Chen, Tiejun wrote:
[...]
> >Hardcoded value?
>
> Yes. Actually, we intend to use this to present that lowmem entry,
>
> tools/firmware/hvmloader/e820.c:
>
> /* Low RAM goes here. Reserve space for special pages. */
> ...
> e820[nr].addr = 0x
On Mon, Apr 13, 2015 at 09:17:04AM +0100, Jan Beulich wrote:
> >>> On 01.04.15 at 11:59, wrote:
> > On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
> >> On 01/04/15 10:20, Stefano Stabellini wrote:
> >> > CC'ing the author of the patch and xen-devel.
> >> > FYI I think that Jan is g
Monday, April 13, 2015, 11:50:51 AM, you wrote:
> On 13/04/15 10:39, Sander Eikelenboom wrote:
>> Hi David,
>>
>> I seem to have spotted some trouble with a 4.0 dom0 kernel with the
>> devel/for-linus-4.1 branch pulled on top.
>>
>> Does this remind you of any specific commits in the devel/for
>>> On 13.04.15 at 12:50, wrote:
> On Mon, 13 Apr 2015, Jan Beulich wrote:
>> >>> On 02.04.15 at 18:49, wrote:
>> > On Wed, 25 Mar 2015, Jan Beulich wrote:
>> >> When a device gets detached from a guest, pciback will clear its
>> >> command register, thus disabling both memory and I/O decoding. T
>>> On 13.04.15 at 13:19, wrote:
> Yes Linux can't fix firmware 1st mode, but
> PCI express spec says what firmware should do in this case:
>
> IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices
>
> With 1.0a device Functions, 96 if the Unsupported Request Reportin
On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
> >>> On 13.04.15 at 13:19, wrote:
> > Yes Linux can't fix firmware 1st mode, but
> > PCI express spec says what firmware should do in this case:
> >
> > IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices
> >
> >
>>> On 10.04.15 at 19:03, wrote:
> osstest service user writes ("[xen-unstable test] 50291: regressions - FAIL"):
>> flight 50291 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/50291/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> incl
On Mon, 13 Apr 2015, Jan Beulich wrote:
> >>> On 13.04.15 at 12:50, wrote:
> > On Mon, 13 Apr 2015, Jan Beulich wrote:
> >> >>> On 02.04.15 at 18:49, wrote:
> >> > On Wed, 25 Mar 2015, Jan Beulich wrote:
> >> >> When a device gets detached from a guest, pciback will clear its
> >> >> command regi
On 13/04/15 12:21, Sander Eikelenboom wrote:
>
> Monday, April 13, 2015, 11:50:51 AM, you wrote:
>
>> On 13/04/15 10:39, Sander Eikelenboom wrote:
>>> Hi David,
>>>
>>> I seem to have spotted some trouble with a 4.0 dom0 kernel with the
>>> devel/for-linus-4.1 branch pulled on top.
>>>
>>> Does
Hi Ian,
On 09/04/15 18:04, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [PATCH v5 p2 16/19] tools/libxl: arm:
> Use an higher value for the GIC phandle"):
>> On 09/04/15 17:52, Ian Jackson wrote:
>>> What would happen if our assumption about the DT compiler were
>>> violated ?
>>
>>
>>> On 01.04.15 at 15:21, wrote:
> Hi Jan,
>
> Any more comments about this series? Thanks a lot!
I think it makes little sense to wait for my review before posting v2
with issues addressed which others have pointed out. I just
returned from vacation, and would have time to look at v1 next
week
Monday, April 13, 2015, 2:07:02 PM, you wrote:
> On 13/04/15 12:21, Sander Eikelenboom wrote:
>>
>> Monday, April 13, 2015, 11:50:51 AM, you wrote:
>>
>>> On 13/04/15 10:39, Sander Eikelenboom wrote:
Hi David,
I seem to have spotted some trouble with a 4.0 dom0 kernel with the
>
On 13/04/15 13:14, Sander Eikelenboom wrote:
>
> Monday, April 13, 2015, 2:07:02 PM, you wrote:
>
>> On 13/04/15 12:21, Sander Eikelenboom wrote:
>>>
>>> Monday, April 13, 2015, 11:50:51 AM, you wrote:
>>>
On 13/04/15 10:39, Sander Eikelenboom wrote:
> Hi David,
>
> I seem to hav
Monday, April 13, 2015, 2:21:21 PM, you wrote:
> On 13/04/15 13:14, Sander Eikelenboom wrote:
>>
>> Monday, April 13, 2015, 2:07:02 PM, you wrote:
>>
>>> On 13/04/15 12:21, Sander Eikelenboom wrote:
Monday, April 13, 2015, 11:50:51 AM, you wrote:
> On 13/04/15 10:39, Sander E
Andrew Cooper writes:
> Save the x86 HVM specific parts of the domain. This is considerably simpler
> than an x86 PV domain. Only the HVM_CONTEXT and HVM_PARAMS records are
> needed.
>
> There is no need for any page normalisation.
>
> Signed-off-by: Andrew Cooper
> CC: Ian Campbell
> CC: Ian
>>> On 13.04.15 at 13:47, wrote:
> On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
>> >>> On 13.04.15 at 13:19, wrote:
>> > Yes Linux can't fix firmware 1st mode, but
>> > PCI express spec says what firmware should do in this case:
>> >
>> > IMPLEMENTATION NOTE Software UR Reporting
>>> On 13.04.15 at 14:01, wrote:
> On Mon, 13 Apr 2015, Jan Beulich wrote:
>> >>> On 13.04.15 at 12:50, wrote:
>> > On Mon, 13 Apr 2015, Jan Beulich wrote:
>> >> While we trust Dom0 to not do outright bad things,
>> >> the hypervisor should still avoid doing things that can go wrong
>> >> due to
On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote:
> >>> On 13.04.15 at 13:47, wrote:
> > On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
> >> >>> On 13.04.15 at 13:19, wrote:
> >> > Yes Linux can't fix firmware 1st mode, but
> >> > PCI express spec says what firmware shoul
>>> On 13.04.15 at 14:47, wrote:
> On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote:
>> Quite possible. Looking at the ITP log we were provided, the UR
>> severity bit is clear (non-fatal), yet the error got surfaced to the
>> OS as a fatal one (I would guess because it validly gets fla
flight 50395 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-freebsd10-i386 10 guest-start fail REGR. vs. 36512
test-i386-i386-pa
On 10/04/15 16:24, Andrew Cooper wrote:
> On 10/04/15 15:19, David Vrabel wrote:
>> asm/spinlock.h should not be included directly.
>>
>> Signed-off-by: David Vrabel
>
> s/asm/xen/g instead of a straight delete?
>
> Otherwise you are relying on pulling in xen/spinlock.h implicitly.
None of thes
On 13/04/15 14:13, David Vrabel wrote:
> On 10/04/15 16:24, Andrew Cooper wrote:
>> On 10/04/15 15:19, David Vrabel wrote:
>>> asm/spinlock.h should not be included directly.
>>>
>>> Signed-off-by: David Vrabel
>> s/asm/xen/g instead of a straight delete?
>>
>> Otherwise you are relying on pulling
On 13/04/15 13:28, Vitaly Kuznetsov wrote:
> Andrew Cooper writes:
>
>> +/*
>> + * Query for a range of HVM parameters and write an HVM_PARAMS record into
>> the
>> + * stream.
>> + */
>> +static int write_hvm_params(struct xc_sr_context *ctx)
>> +{
>> +static const unsigned int params[] = {
On 13/04/15 11:56, George Dunlap wrote:
On Thu, Apr 9, 2015 at 5:36 PM, Stefano Stabellini
wrote:
On Thu, 9 Apr 2015, Eric Dumazet wrote:
On Thu, 2015-04-09 at 16:46 +0100, Stefano Stabellini wrote:
Hi all,
I found a performance regression when running netperf -t TCP_MAERTS from
an external
On 27/03/15 13:06, Jonathan Davies wrote:
> On 26/03/15 17:14, Eric Dumazet wrote:
>> On Thu, 2015-03-26 at 16:46 +, Jonathan Davies wrote:
>>> Network drivers with slow TX completion can experience poor network
>>> transmit
>>> throughput, limited by hitting the sk_wmem_alloc limit check in
>>
On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
> Is the problem perhaps that netback/netfront delays TX completion?
> Would it be better to see if that can be addressed properly, so that
> the original purpose of the patch (fighting bufferbloat) can be
> achieved while not degrading perfo
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 50291: regressions -
FAIL"):
> On 10.04.15 at 19:03, wrote:
> > These were the only problems in this flight. Under the circumstances
> > I think we would be justified in force pushing to xen.git#master:
> >
> >> version targeted for testi
>>> On 13.04.15 at 15:55, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 50291: regressions -
> FAIL"):
>> On 10.04.15 at 19:03, wrote:
>> > These were the only problems in this flight. Under the circumstances
>> > I think we would be justified in force pushing to xen.git#mas
On Mon, 2015-04-13 at 14:46 +0100, David Vrabel wrote:
> > And the proof-of-concept patch for idea (b) I used was:
> >
> > @@ -552,6 +552,8 @@ static int xennet_start_xmit(struct sk_buff *skb,
> > struct net_device *dev)
> > goto drop;
> > }
> >
> > +skb_orphan(skb);
> > +
>>> On 31.03.15 at 17:57, wrote:
> Currently, _xmalloc() supports zero-sized allocations by returning a sentinel
> poisoned pointer.
>
> I posit that there are no legitimate situation for any code in the
> hypervisor
> to make a zero sized allocation.
I'm afraid there are, and we ran into them
Here are some more which I propose to force push. In each case I show
all the blocking tests mentioned in the osstest test report.
osstest service user writes ("[xen-4.5-testing test] 50373: regressions -
FAIL"):
> flight 50373 xen-4.5-testing real [real]
...
> test-amd64-i386-freebsd10-amd64
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 50291: regressions -
FAIL"):
> Thanks! Perhaps similarly consider flight 50355 a good one for 4.5 then?
That would be:
osstest service user writes ("[xen-4.5-testing test] 50355: regressions -
trouble: broken/fail/pass"):
> flight 50355
Use the option like 'pci=[ '07:10,1', '0b:10.1', '81:10.1']' in HVM
guest configuration file to assign more than one VF PCI devices to
a guest, after the guest boot up, detach the VFs in sequence by
'xl pci-detach $DOM_ID $VF_BDF', and then attach the VFs by
'xl pci-attach $DOM_ID $VF_BDF' in seque
On 13/04/2015 16:12, Liang Li wrote:
> 2. Do the attach and detach operation with a time interval. eg. 10s.
>
> The error message will not disappear if retry, in this case, it's
> a bug.
>
> In the 'xen_pt_region_add' and 'xen_pt_region_del', we should only care
> about the 'xen-pc
>>> On 01.04.15 at 17:31, wrote:
> case XEN_DOMCTL_gettscinfo:
> -{
> -xen_guest_tsc_info_t info;
> -
> -ret = -EINVAL;
> -if ( d == current->domain ) /* no domain_pause() */
> -break;
> -
> -domain_pause(d);
> -tsc_get_info(d, &info.ts
>>> On 02.04.15 at 10:24, wrote:
> Some EFI firmware implementations may place the SMBIOS table in RAM
> marked as BootServicesData, which Xen does not consider as reserved.
> When dom0 tries to access the SMBIOS, the region is not contained in the
> initial P2M and it crashes with a page fault. T
On 04/13/2015 12:21 AM, 蒋雄伟(蒋冲) wrote:
>
> Hi，everyone
>
>
> We would like to obtain the distribution of CPU-specific hardware events
> such as clock cycles and cache and TLB misses and branch-miss and etc. in Xen
> environment . It is said that Xenoprof can be used to do so. We use Intel'
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
> >>+void __init __pv_init_lock_hash(void)
> >>+{
> >>+ int pv_hash_size = 4 * num_possible_cpus();
> >>+
> >>+ if (pv_hash_size< (1U<< LFSR_MIN_BITS))
> >>+ pv_hash_size = (1U<< LFSR_MIN_BITS);
> >>+ /*
> >>+* Allo
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 April 2015 19:49
> To: xen-devel@lists.xen.org
> Cc: Ian Campbell; Ian Jackson; Wei Liu; Paul Durrant; Jan Beulich
> Subject: [PATCH v4 3/3] Revert "x86/hvm: wait for at least one ioreq server
> to be enabled"
>
>
On 13/04/15 15:05, Eric Dumazet wrote:
> On Mon, 2015-04-13 at 14:46 +0100, David Vrabel wrote:
>
>>> And the proof-of-concept patch for idea (b) I used was:
>>>
>>> @@ -552,6 +552,8 @@ static int xennet_start_xmit(struct sk_buff *skb,
>>> struct net_device *dev)
>>> goto drop;
>>>
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
> >>+static void pv_wait_head(struct qspinlock *lock, struct mcs_spinlock *node)
> >>+{
> >>+ struct __qspinlock *l = (void *)lock;
> >>+ struct qspinlock **lp = NULL;
> >>+ struct pv_node *pn = (struct pv_node *)node;
> >>+ int
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
> >>+__visible void __pv_queue_spin_unlock(struct qspinlock *lock)
> >>+{
> >>+ struct __qspinlock *l = (void *)lock;
> >>+ struct pv_node *node;
> >>+
> >>+ if (likely(cmpxchg(&l->locked, _Q_LOCKED_VAL, 0) == _Q_LOCKED_VAL))
> >>+
Monday, April 13, 2015, 2:21:21 PM, you wrote:
> On 13/04/15 13:14, Sander Eikelenboom wrote:
>>
>> Monday, April 13, 2015, 2:07:02 PM, you wrote:
>>
>>> On 13/04/15 12:21, Sander Eikelenboom wrote:
Monday, April 13, 2015, 11:50:51 AM, you wrote:
> On 13/04/15 10:39, Sander E
On Mon, 13 Apr 2015, Jan Beulich wrote:
> >>> On 13.04.15 at 14:01, wrote:
> > On Mon, 13 Apr 2015, Jan Beulich wrote:
> >> >>> On 13.04.15 at 12:50, wrote:
> >> > On Mon, 13 Apr 2015, Jan Beulich wrote:
> >> >> While we trust Dom0 to not do outright bad things,
> >> >> the hypervisor should stil
>>> On 08.04.15 at 11:20, wrote:
> On Tue, Apr 7, 2015 at 5:11 PM, Andrew Cooper
> wrote:
>> On 07/04/15 14:27, Liang Li wrote:
>>> This bug will be trigged when NMI happen in the L2 guest. The current
>>> code handles the NMI incorrectly. According to Intel SDM 31.7.1.2
>>> (Resuming Guest Soft
On 13/04/15 15:27, Jan Beulich wrote:
> >>> On 01.04.15 at 17:31, wrote:
>> case XEN_DOMCTL_gettscinfo:
>> -{
>> -xen_guest_tsc_info_t info;
>> -
>> -ret = -EINVAL;
>> -if ( d == current->domain ) /* no domain_pause() */
>> -break;
>> -
>> -dom
On 04/13/2015 10:47 AM, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
+void __init __pv_init_lock_hash(void)
+{
+ int pv_hash_size = 4 * num_possible_cpus();
+
+ if (pv_hash_size< (1U<< LFSR_MIN_BITS))
+ pv_hash_size = (1U<< LF
* latch curr/currd once at start
* drop redundant "ret = 0" and braces
* use "copyback = 1" when appropriate
* move break statements inside case-specific braced scopes
* don't bother check for NULL before calling xfree()
* eliminate trailing whitespace
* Xen style corrections
Signed-off-by:
On 04/13/2015 11:08 AM, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
+static void pv_wait_head(struct qspinlock *lock, struct mcs_spinlock *node)
+{
+ struct __qspinlock *l = (void *)lock;
+ struct qspinlock **lp = NULL;
+ struct pv_node *
>>> On 07.04.15 at 18:57, wrote:
> On 04/07/2015 12:04 PM, Andrew Cooper wrote:
>> On 06/04/15 23:12, Boris Ostrovsky wrote:
>>> A number of changes to XEN_SYSCTL_numainfo interface:
>>>
>>> * Make sysctl NUMA topology query use fewer copies by combining some
>>>fields into a single structure
This will prevent a hard to track down bug. It is related to
commit ffdb781883abd3215287ba1b1853f3d437d1240c
x86/hvm: prevent gcc uninitialised var warning
Which will preset "gmfn" to ~0UL.
This code will check if there is a path where bufioreq_pfn is passed
to hvm_free_ioreq_gmfn() and it is u
gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between
uint64_t and unsigned long.
Signed-off-by: Andrew Cooper
CC: Konrad Rzeszutek Wilk
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
This needs backporting to 4.5
---
tools/libxc/xc_domain.c |2 +-
1 file changed, 1 i
This changes:
(XEN) Early fatal page fault at e008:82d080164252 (cr2=,
ec=)
(XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] arch_domain_create+0x3e/0x4ef
...
(XEN) Xen call trace:
(XEN)[] arch_domain_create+0x3e/0x
gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between
uint64_t and unsigned long.
Signed-off-by: Andrew Cooper
CC: Konrad Rzeszutek Wilk
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
This needs backporting to 4.2
---
tools/libxc/xc_domain.c | 13 +
1 file c
If QEMU has called on xc_domain_setmaxmem to add more memory for
option ROMs, domain restore needs to also increase the memory.
Signed-off-by: Don Slutz
---
To see the hvmloader loader issue:
xl cre -p e1000x8.xfg
xl save e1000x8 e1000x8.save
xl restore e1000x8.save
With e1000x8.xfg:
On 13/04/15 17:04, Don Slutz wrote:
> This changes:
>
> (XEN) Early fatal page fault at e008:82d080164252 (cr2=,
> ec=)
> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] arch_domain_create+0x3e/0x4ef
> ...
> (XEN) X
On 04/13/2015 11:09 AM, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 05:41:44PM -0400, Waiman Long wrote:
+__visible void __pv_queue_spin_unlock(struct qspinlock *lock)
+{
+ struct __qspinlock *l = (void *)lock;
+ struct pv_node *node;
+
+ if (likely(cmpxchg(&l->locked, _Q_LOC
On 13/04/15 17:09, Don Slutz wrote:
> If QEMU has called on xc_domain_setmaxmem to add more memory for
> option ROMs, domain restore needs to also increase the memory.
>
> Signed-off-by: Don Slutz
hvmloader has no interaction with xc_domain_restore().
It is xl's job to propagate the current memo
Andrew Cooper writes ("[Xen-devel] [PATCH] tools/libxc: Fix build of 32bit
toolstacks on CentOS 5.x following XSA-125"):
> gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between
> uint64_t and unsigned long.
>
> Signed-off-by: Andrew Cooper
> CC: Konrad Rzeszutek Wilk
> CC: Ian
On Mon, 13 Apr 2015, George Dunlap wrote:
> On 04/10/2015 03:29 PM, Stefano Stabellini wrote:
> >> +arg_parse_cmd=\
> >> +"local -a args;
> >> +local _a;
> >> +local _vn;
> >> +local _m;
> >> +
> >> +_m=true;
> >> +
> >> +for _a in \"\$@\" ; do
> >> +false && echo \"Evaluating \${_a} [[ \"\${_a
1 - 100 of 118 matches
Mail list logo
