> -Original Message-
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: jbeul...@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>
> Il 12/11/2014 07:58, Hu, Rober
Hi,
Roger is correct: after I applied that patch and reinstalled qemu, modified
/etc/init.d/xencommons to use the modified version of qemu to provide disk
backend, I finally succeeded to create a xen guest! I noticed that this
patch was proposed yesterday: just in-time to solve my problem. :-)
r
Ingo,
could you take the patches, please?
Juergen
On 11/03/2014 02:01 PM, Juergen Gross wrote:
The x86 architecture offers via the PAT (Page Attribute Table) a way to
specify different caching modes in page table entries. The PAT MSR contains
8 entries each specifying one of 6 possible cache
On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
+ mfn_save = virt_to_mfn(buf);
+
+ while (xen_remap_mfn != INVALID_P2M_ENTRY) {
So the 'list' is constructed by going forward - that is from low-numbered
PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
other way
flight 31532 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31532/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start
flight 31530 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 31241
test-amd64-i386-rumpu
flight 31510 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 31489
Regressions which ar
On 2014/11/13 11:09, Chen, Tiejun wrote:
On 2014/11/12 16:55, Jan Beulich wrote:
On 12.11.14 at 04:05, wrote:
I don't see any feedback to this point, so I think you still prefer we
should do all check in the callback function.
As a draft this looks reasonable, but there are various bugs to
On Thu, Nov 13, 2014 at 3:46 PM, Martin Lucina wrote:
>> > Following is the high-level description from the Git commit:
>>
>> Can you also post an example of the usage of your CLI tool? Actually,
>> can you post a rough description of the entire process that a user would
>> have to follow, i.e. c
At 14:18 -0500 on 13 Nov (1415884696), Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 13, 2014 at 04:18:58PM +, Jan Beulich wrote:
> > >>> On 13.11.14 at 17:03, wrote:
> > > Being a feature that has only been used by ia64 and/or ppc it
> > > doesn't seem like we need to keep it any longer in the t
On Thu, Nov 13, 2014 at 07:54:57AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> >>Introduces lookup_pmd_address() to get the address of the pmd entry
> >>related to a virtual address in the cur
On Thu, Nov 13, 2014 at 07:49:24AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
> >>@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
> >>unsigned long max_pfn;
> >>unsigned long pfn;
> >>
> >>-if (xen_feature(XENFEAT_auto_tr
> >>+ mfn_save = virt_to_mfn(buf);
> >>+
> >>+ while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >
> >So the 'list' is constructed by going forward - that is from low-numbered
> >PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >other way - from the highest PFN to the lowest PF
flight 31531 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels
fail REGR. vs. 31437
tes
flight 31506 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30767
Tests which are failing i
On Thu, Nov 13, 2014 at 06:42:09PM +0100, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backend
> (Qdisk):
>
> - Keep track of memory regions where persistent grants have been mapped
>since we need to unmap them as a whole. It is not possible to u
On 13/11/14 18:57, Martin Lucina wrote:
Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
that it's not supposed to be used as a normal /etc.
I'd prefer it to be completely hidden from the user. But sure, call it
stubetc for now.
This brings up another question; what
On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
> Thanks Konrad,
>
> Thursday, November 13, 2014, 4:03:38 PM, you wrote:
>
> >> Yes I do verify the write. How do I check this from Dom0?
>
> > You can crank up the debug volume in xen-pciback. Recompile the kernel
> > and put '#defin
On 11/13/2014 05:42 PM, Roger Pau Monne wrote:
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Keep track of memory regions where persistent grants have been mapped
since we need to unmap them as a whole. It is not possible to unmap a
single grant
Thanks Konrad,
Thursday, November 13, 2014, 4:03:38 PM, you wrote:
>> Yes I do verify the write. How do I check this from Dom0?
> You can crank up the debug volume in xen-pciback. Recompile the kernel
> and put '#define DEBUG 1' at the start of the .c files.
> Interestingly enough I saw this is
On Thu, Nov 13, 2014 at 07:05:45PM +, Lars Kurth wrote:
> Ian,
>
> I totally agree. I don't think that limited maintainership in xen.git is
> an issue.
>
> If I look at the process, it states that
> a) A committer needs to nominate the candidate - tick
> b) A private election amongst committ
On Thu, Nov 13, 2014 at 04:18:58PM +, Jan Beulich wrote:
> >>> On 13.11.14 at 17:03, wrote:
> > Being a feature that has only been used by ia64 and/or ppc it
> > doesn't seem like we need to keep it any longer in the tree.
> >
> > So remove it.
> >
> > Signed-off-by: Boris Ostrovsky
> > Sig
On Thu, Nov 13, 2014 at 04:02:47PM +, Andrew Cooper wrote:
> Hi,
>
> While attempting to test Konrads new interrupt injection logic, I got
> blocked behind yet another Pygrub bug caused by c/s d1b93ea
>
> This is the first time I have looked into the issue, but a cursory
> inspection of the f
Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.
Also while we're at it, normalize init and dispose of
libxl_device_disk structures. This means calling init and dispose in
the actual functions where they are declared.
This in turn means
Ian,
I totally agree. I don't think that limited maintainership in xen.git is
an issue.
If I look at the process, it states that
a) A committer needs to nominate the candidate - tick
b) A private election amongst committers of the project must be held using
a voting form created by me, and then
On Thu, Nov 13, 2014 at 05:27:09PM +, Anthony PERARD wrote:
> Since a message to XenStore have a lenght of type UINT32, have
> XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
>
> This patch replaces the type of Len in WRITE_REQUEST and the type of the
> argument Len of XenSt
On Thu, Nov 13, 2014 at 02:49:07PM -0300, Simon Martin wrote:
> Hello Jan,
>
> >>
> >> Yes, the first thing I do in the driver is set the PCI configuration
> >> access bits to 7 that should enable IO space, Memory Space and Master
> >> BUS access.
> >>
> >> As a test I disabled this and all
I would like to propose that we make Konrad Wilk a Xen committer.
Konrad is of course already a committer to Linux's Xen support. IMO
he should formally have the authority of a committer in our project,
even though his maintainership in xen.git itself is limited.
Thanks,
Ian.
___
po...@iki.fi said:
> On 13/11/14 17:07, Martin Lucina wrote:
> > po...@iki.fi said:
> >> Actually, hmm, there's already an image for /etc available. I
> >> understood from irc discussion that you needed slight modifications to
> >> passwd for mathopd. In case your changes don't conflict with what
On Wed, Nov 12, 2014 at 05:28:39PM +, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 05:04:23PM +, Wei Liu wrote:
> > > This small series change the behavior of
> > > libxl_retrieve_domain_configuration,
> > > to make it
On Thu, 13 Nov 2014 18:22:17 +0100
Daniel Kiper wrote:
> Hi Petr,
>
> On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> > Hi all,
> >
> > this thread got somehow forgotten because of vacations...
> > Anyway, read below.
> >
> > On Tue, 24 Jul 2012 15:54:10 +0200
> > Daniel Kiper w
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Keep track of memory regions where persistent grants have been mapped
since we need to unmap them as a whole. It is not possible to unmap a
single grant if it has been batch-mapped. A new check has also be
Hello Jan,
>>
>> Yes, the first thing I do in the driver is set the PCI configuration
>> access bits to 7 that should enable IO space, Memory Space and Master
>> BUS access.
>>
>> As a test I disabled this and all reads to the PCI device return -1,
>> even the first one.
> I implied your ea
George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108
process post-mortem"):
> On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
> wrote:
> > III. Information-sharing
> >
...
> > List members are allowed to share fixes to embargoed issues,
> > analys
Hi Petr,
On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
>
> On Tue, 24 Jul 2012 15:54:10 +0200
> Daniel Kiper wrote:
>
> > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> >
Since a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.
This patch should avoid to have type
On 13/11/14 17:07, Martin Lucina wrote:
po...@iki.fi said:
Actually, hmm, there's already an image for /etc available. I
understood from irc discussion that you needed slight modifications to
passwd for mathopd. In case your changes don't conflict with what's
already up there, you could just u
po...@iki.fi said:
> Actually, hmm, there's already an image for /etc available. I
> understood from irc discussion that you needed slight modifications to
> passwd for mathopd. In case your changes don't conflict with what's
> already up there, you could just update the existing downloadable
On 13/11/14 15:46, Martin Lucina wrote:
Following is the high-level description from the Git commit:
Can you also post an example of the usage of your CLI tool? Actually,
can you post a rough description of the entire process that a user would
have to follow, i.e. compile, configure, run.
Ru
On Wed, Nov 12, 2014 at 4:48 PM, Andrew Cooper
wrote:
> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > This patch series aims to clean up the mem_event subsystem within Xen.
> The
> > original use-case for this system was to allow external helper
> applications
> > running in privileged domains to
On Wed, Nov 12, 2014 at 4:58 PM, Andrew Cooper
wrote:
> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/mem_event.h
> b/xen/include/public/mem_event.h
> > index 599f9e8..c0e9394 100644
> > --- a/xen/include/public/mem_event.h
> > +++ b/xen/include/public/mem_event.h
On 27 October 2014 10:34, Ian Campbell wrote:
> On Sun, 2014-10-26 at 09:51 +, Thomas Leonard wrote:
>> On 21 October 2014 11:50, Ian Campbell wrote:
>> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
>> >> Based on an initial patch by Karim Raslan.
>> >>
>> >> Signed-off-by: Karim
El 13/11/14 a les 16.36, Stefano Stabellini ha escrit:
> On Thu, 13 Nov 2014, Roger Pau Monne wrote:
>> @@ -421,7 +451,17 @@ static int ioreq_map(struct ioreq *ioreq)
>> }
>> }
>> }
>> -if (ioreq->blkdev->feature_persistent) {
>> +if (ioreq->blkdev->feature_persis
>>> On 13.11.14 at 17:03, wrote:
> Being a feature that has only been used by ia64 and/or ppc it
> doesn't seem like we need to keep it any longer in the tree.
>
> So remove it.
>
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Tim Deegan
Acked-by: Jan Beulich
___
Ian Campbell writes ("Re: [OSSTEST PATCH 0/9] Host allocation scoring
improvements"):
> On Tue, 2014-11-11 at 19:41 +, Ian Jackson wrote:
> > Here, I'm trying to fix the way that osstest gets far too obsessed
> > about particular failing hosts.
>
> All fine by me, not that I've really grokked
>>> On 13.11.14 at 16:46, wrote:
> That leaves paging_log_dirty_op(). The inner loops of that function
> are already set up to be preempted for softirqs, &c. I wonder could
> we arrange for it to map the first N pages of bitmap before taking any
> locks, and then drop the locks after that many p
Hi,
While attempting to test Konrads new interrupt injection logic, I got
blocked behind yet another Pygrub bug caused by c/s d1b93ea
This is the first time I have looked into the issue, but a cursory
inspection of the first hunk shows that it cannot possibly be correct as
self._default is either
Being a feature that has only been used by ia64 and/or ppc it
doesn't seem like we need to keep it any longer in the tree.
So remove it.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Tim Deegan
---
This was suggested by Boris a while ago and seems to have stalled.
v2: leave public header in pl
We rely on the domain existing after xenstore-ls's main has called
exit, so that we can do our own xenstore-ls in dom0 and check the
results.
Previously, this happened by accident because the rump kernel would,
after _exit, call a minios function which crashes the domain. New
rump kernels don't d
>>> On 13.11.14 at 16:07, wrote:
> Thanks Jan,
>
> Thursday, November 13, 2014, 11:08:33 AM, you wrote:
>
> On 13.11.14 at 14:29, wrote:
>>> I am having 2 major problems at the moment.
>>>
>>> 1.- Access to the PCI device from the PV will fail the second time I
>>> create it UNLESS I call
Hi all,
this thread got somehow forgotten because of vacations...
Anyway, read below.
On Tue, 24 Jul 2012 15:54:10 +0200
Daniel Kiper wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > Hi Petr,
> > >
> > >
> > Following is the high-level description from the Git commit:
>
> Can you also post an example of the usage of your CLI tool? Actually,
> can you post a rough description of the entire process that a user would
> have to follow, i.e. compile, configure, run.
Running "xr" with no parameters
At 12:03 +0200 on 16 Oct (1413457382), Roger Pau Monné wrote:
> El 16/10/14 a les 11.20, Tim Deegan ha escrit:
> > Ah, I see. This is the _caller_'s p2m lock but the _target_'s paging
> > lock. Holding the caller's p2m lock to unstick this seems a bit of a
> > strange answer -- the paging op migh
On Thu, 13 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backend
> (Qdisk):
>
> - Keep track of memory regions where persistent grants have been mapped
>since we need to unmap them as a whole. It is not possible to unmap a
>single gr
Thanks Jan,
Thursday, November 13, 2014, 11:08:33 AM, you wrote:
On 13.11.14 at 14:29, wrote:
>> I am having 2 major problems at the moment.
>>
>> 1.- Access to the PCI device from the PV will fail the second time I
>> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
>>
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Keep track of memory regions where persistent grants have been mapped
since we need to unmap them as a whole. It is not possible to unmap a
single grant if it has been batch-mapped.
- Unmap persistent gra
>>> On 13.11.14 at 14:29, wrote:
> I am having 2 major problems at the moment.
>
> 1.- Access to the PCI device from the PV will fail the second time I
> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
> between each creation. If I don't do this then all PCI accesses return
>
On 13/11/14 11:22, Martin Lucina wrote:
back in July there was some discussion on configuring rump kernel
application stacks:
http://thread.gmane.org/gmane.comp.rumpkernel.user/321
Some proposals were made, but no actual implementation work was done. In
the mean time, I have implemented the simp
On November 13, 2014 4:15:26 AM EST, Juergen Gross wrote:
>On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
>>> Today get_phys_to_machine() is always called when the mfn for a pfn
>>> is to be obtained. Add a wrapper __pfn_to_mf
Hi all,
I am back on my virtual machine once again and have run into a bit of
a problem (once again). So I am coming to you cap in hand...
I am having 2 major problems at the moment.
1.- Access to the PCI device from the PV will fail the second time I
create it UNLESS I call xl pci-assignable-re
flight 31520 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
Il 08/07/2014 10:53, David Jaša ha scritto:
Hi,
On Út, 2
flight 31517 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603
test-amd64-i386-pai
Ian Jackson writes ("Re: [rumpuserxen test] 31509: regressions - FAIL"):
...
> This is weird.
Actually, I think, the problem is that the rumpkernel now exits
successfully rather than crashing, and my domain config file says only
`on_crash="preserve"' and not `on_shutdown="preserve"'.
So this is a
On Wed, 2014-11-12 at 10:04 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> Also I want clarify on
Am 12.11.2014 um 18:41 hat Stefano Stabellini geschrieben:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> > This patch fixes two issues with persistent grants and the disk PV backend
> > (Qdisk):
> >
> > - Don't use batch mappings when using persistent grants, doing so prevents
> >unmapping
On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote:
> > > By "active" here, do you you mean "live" (vs paused)?
> > Means the domain is started (no matter is running or paused).
> > vs (libvirt defines a domain but not started).
> > Here, I should update this to:
> > 3). take disk snapshot
(Cc-ing xen-devel as this is relevant to general use of
"application-specific" domains, MirageOS, etc.)
Hi,
back in July there was some discussion on configuring rump kernel
application stacks:
http://thread.gmane.org/gmane.comp.rumpkernel.user/321
Some proposals were made, but no actual impleme
xen.org writes ("[rumpuserxen test] 31509: regressions - FAIL"):
> flight 31509 rumpuserxen real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-rump
On 13.11.2014 11:57, Roger Pau Monné wrote:
> El 12/11/14 a les 19.41, Xing Lin ha escrit:
>> Hi,
>>
>> I am aware that Xen via libvirt is in the group C support for openstack but
>> since I am not able to install xenserver iso at compute machines I have, I
>> have to consider to use xen with libvi
On Thu, 2014-11-13 at 08:12 +, Ian Campbell wrote:
> On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:
>
> >
> > [ 9448.347994] [ cut here ]
> > [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> > /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> > ===
El 12/11/14 a les 19.41, Xing Lin ha escrit:
> Hi,
>
> I am aware that Xen via libvirt is in the group C support for openstack but
> since I am not able to install xenserver iso at compute machines I have, I
> have to consider to use xen with libvirt (xcp-xapi is not available for
> ubuntu14.04).
>>> On 13.11.14 at 11:38, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>> +
>>> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> + return
On 12/11/14 18:41, Xing Lin wrote:
> Hi,
>
> I am aware that Xen via libvirt is in the group C support for openstack
> but since I am not able to install xenserver iso at compute machines I
> have, I have to consider to use xen with libvirt (xcp-xapi is not
> available for ubuntu14.04). I have th
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT)
>>> On 13.11.14 at 11:25, wrote:
On 12.11.14 at 16:25, wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>> struct pdev_archdata {
>> };
>>
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
>
> Is there a particular
On 13/11/14 10:25, Jan Beulich wrote:
On 12.11.14 at 16:25, wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>> struct pdev_archdata {
>> };
>>
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
>
> Is there a particu
>>> On 12.11.14 at 16:25, wrote:
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
> struct pdev_archdata {
> };
>
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather than in
dma-ma
Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
Il 08/07/2014 10:53, David Jaša ha scritto:
Hi,
On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>> On 12.11.14 at 16:55, wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1
On Thu, Nov 13, 2014 at 01:22:49AM +, Hu, Robert wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; jbeul...@suse.com; wei.l...@citrix.com
> > Subject: Re: [Xen-d
On Thu, 2014-11-13 at 01:22 +, Hu, Robert wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; jbeul...@suse.com; wei.l...@citrix.com
> > Subject: Re: [Xen-devel] [
On 11/11/2014 06:47 PM, David Vrabel wrote:
On 11/11/14 05:43, Juergen Gross wrote:
At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenev
On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
Today get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machi
On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
> To me this looks like some memory corruption by some unknown code
> writing into some random memory space, which happens to be the tdb here.
I wonder if running xenstored under valgrind would be useful. I think
you'd want to stop xenstored f
All,
while the 3 month period since the previous stable releases would
expire at the beginning of December, looking at the number of
changes in the stable trees I don't think starting preparations right
now would make much sense. Unless I hear severe objections to
this plan, and unless 4.5 gets si
El 12/11/14 a les 18.41, Stefano Stabellini ha escrit:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
>> This patch fixes two issues with persistent grants and the disk PV backend
>> (Qdisk):
>>
>> - Don't use batch mappings when using persistent grants, doing so prevents
>>unmapping single gra
>>> On 13.11.14 at 00:52, wrote:
> Hello,
>
> I am trying to set up a shared page between the hypervisor and a Linux guest
> kernel. In Xen I am doing:
>
> void *ptr = alloc_xenheap_page();
> share_xen_page_with_guest(virt_to_page(ptr), current->domain,
> XENSHARE_writable);
> unsigned int mfn
>>> On 13.11.14 at 03:32, wrote:
> Hi,
>
> This is a separated report for bug
> http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
>
> Environment:
>
> Service Arch (ia32/ia32e/IA64): ia32e
> Guest Arch (ia32/ia32e/IA64):
> Guest OS Type (Linux/Windows):
> Chan
On Wed, 2014-11-12 at 17:31 +, George Dunlap wrote:
> @@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
> rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
> if (rc) {
> fprintf(stderr, "libxl_device_disk_remove failed.\n");
> +return 1;
> }
>
>>> On 13.11.14 at 03:23, wrote:
> Bug detailed description:
> --
> Assign multi PF devices(I350, 82576, 82599) to installing Windows8.1 guest
> VM
> with xl tool. After guest boot up, one PF could not get IP address and shows
> as
> "Network cable unplugged", while other
>>> On 13.11.14 at 06:31, wrote:
Apart from the subject being kind of wrong (you're not turning it on
by default, but only expose it if the hardware supports it), ...
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy(
>
On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:
>
> [ 9448.347994] [ cut here ]
> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> more message ignored
The most interesting bits of the message
93 matches
Mail list logo
