* [PATCH 3/5] iommu/amd: Fix group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
If acpihid_device_group() finds an existing group for the relevant
devid, it should be taking an additional reference on that group.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595ee11b6..4ef05691ceb1 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -373,6 +373,8 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
if (!entry->group)
entry->group = generic_device_group(dev);
+ else
+ __iommu_group_get(entry->group);
return entry->group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 3/5] iommu/amd: Fix group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
If acpihid_device_group() finds an existing group for the relevant
devid, it should be taking an additional reference on that group.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595ee11b6..4ef05691ceb1 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -373,6 +373,8 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
if (!entry->group)
entry->group = generic_device_group(dev);
+ else
+ __iommu_group_get(entry->group);
return entry->group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..f5591f6aef49 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..f5591f6aef49 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
From: Paolo Bonzini @ 2016-11-09 12:47 UTC (permalink / raw)
To: Stefan Hajnoczi, Ketan Nilangekar
Cc: Ashish Mittal, qemu-devel@nongnu.org, kwolf@redhat.com,
armbru@redhat.com, berrange@redhat.com, jcody@redhat.com,
famz@redhat.com, Ashish Mittal, Abhijit Dey
In-Reply-To: <20161108153915.GA11274@stefanha-x1.localdomain>
On 08/11/2016 16:39, Stefan Hajnoczi wrote:
> The current status is:
>
> 1. virtio-blk and virtio-scsi support multiple queues but these queues
> are processed from a single thread today.
>
> 2. MemoryRegions can be marked with !global_locking so its handler
> functions are dispatched without taking the QEMU global mutex. This
> allows device emulation to run in multiple threads.
Alternatively, virtio-blk and virtio-scsi can already use ioeventfd and
"-object iothread,id=FOO -device virtio-blk-pci,iothread=FOO" to let
device emulation run in a separate thread that doesn't take the QEMU
global mutex.
> 3. Paolo Bonzini (CCed) is currently working on make the block layer
> (BlockDriverState and co) support access from multiple threads and
> multiqueue. This is work in progress.
>
> If you are interested in this work keep an eye out for patch series from
> Paolo Bonzini and Fam Zheng.
The first part (drop RFifoLock) was committed for 2.8. It's a
relatively long road, but these are the currently ready parts of the work:
- take AioContext acquire/release in small critical sections
- push AioContext down to individual callbacks
- make BlockDriverState thread-safe
The latter needs rebasing after the last changes to dirty bitmaps, but I
think these patches should be ready for 2.9.
These are the planned bits:
- replace AioContext with fine-grained mutex in bdrv_aio_*
- protect everything with CoMutex in bdrv_co_*
- remove aio_context_acquire/release
For now I was not planning to make network backends support multiqueue,
only files.
Paolo
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Saint Germain @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-btrfs; +Cc: Niccolò Belli
In-Reply-To: <8f0cf023-7189-4de1-a72c-38a4deb8a049@linuxsystems.it>
On Wed, 09 Nov 2016 12:24:51 +0100, Niccolò Belli
<darkbasic@linuxsystems.it> wrote :
>
> On martedì 8 novembre 2016 23:36:25 CET, Saint Germain wrote:
> > Please be aware of these other similar softwares:
> > - jdupes: https://github.com/jbruchon/jdupes
> > - rmlint: https://github.com/sahib/rmlint
> > And of course fdupes.
> >
> > Some intesting points I have seen in them:
> > - use xxhash to identify potential duplicates (huge speedup)
> > - ability to deduplicate read-only snapshots
> > - identify potential reflinked files (see also my email here:
> > https://www.spinics.net/lists/linux-btrfs/msg60081.html)
> > - ability to filter out hardlinks
> > - triangle problem: see jdupes readme
> > - jdupes has started the process to be included in Debian
> >
> > I hope that will help and that you can share some codes with them !
> >
> Hi,
> What do you think about jdupes? I'm searching an alternative to
> duperemove and rmlint doesn't seem to support btrfs deduplication, so
> I would like to try jdupes. My main problem with duperemove is a
> memory leak, also it seems to lead to greater disk usage:
> https://github.com/markfasheh/duperemove/issues/163
rmlint is supporting btrfs deduplication:
rmlint --algorithm=xxhash --types="duplicates" --hidden --config=sh:handler=clone --no-hardlinked
I've used jdupes and rmlint to deduplicate 2TB with 4GB RAM and it took
a few hours. So it is acceptable from a performance point of view.
The problems I found have been corrected by both.
Jdupes author is really kind and reactive !
^ permalink raw reply
* Re: NVAC "No Signal"
From: Pierre Moreau @ 2016-11-09 12:48 UTC (permalink / raw)
To: poma; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Ben Skeggs
In-Reply-To: <43b17bb3-7b12-b1be-c608-702ebdfd8522-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]
I retested with both 4.8.4, Ben’s linux-4.9 and linux-4.10 branches (so only
the linux-4.10 branch had the atomic+MST patches).
For all branches, if I bootplug the external screen, I get nothing on the
external screen, and the laptop screen is frozen with some mix of images (but
the laptop itself is not locked up), nothing in dmesg. If I hotplug the screen,
the laptop screen is not frozen, but starting with linux-4.10, I get an EVO
timeout when turning off the external monitor. Adding your patch did not change
anything for me.
Looks like I’ll need to spend some more time testing and bisecting those
issues…
Pierre
On 06:12 am - Nov 08 2016, poma wrote:
> On 21.10.2016 10:56, Pierre Moreau wrote:
> > On 01:15 am - Oct 21 2016, Lukas Wunner wrote:
> >> On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
> >>> On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
> >>>> For example, my laptop (which also has an NVAC) has been triggering the
> >>>> no-signal message on external monitors way before Ben???s patch landed,
> >>>> but only for some adapters. I haven???t tried Ben???s patch yet, nor
> >>>> yours, but I will certainly do it, and see what effect each of them has.
> >>>
> >>> The external DP port on your MBP5,3 is switchable between GPUs and
> >>> the apple-gmux driver switches it in unison with the panel. Thus
> >>> the NVAC cannot drive external displays when gmux is switched to
> >>> the MCP79. (You probably were aware of this, just wanted to mention
> >> ^^^^^
> >> I meant G96, sorry I mixed it up.
> >>
> >> Lukas
> >
> > Yes, that bit had stayed in my memory, that switching between the two GPUs
> > would not only switch them for the laptop screen, but for the external ones as
> > well. IIRC, I am getting the no signal in both cases, but I need to retest.
> >
> > Pierre
>
> Any news related on your side?
>
>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [Qemu-devel] [Bug 721793] Re: QEMU freezes on startup (100% CPU utilization)
From: Thomas Huth @ 2016-11-09 12:40 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20110219143658.9055.78373.malonedeb@gandwana.canonical.com>
Closing as "Fix released" according to comment #3
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721793
Title:
QEMU freezes on startup (100% CPU utilization)
Status in QEMU:
Fix Released
Bug description:
0.12.5 was the last version of QEMU that runs ok and boots any os
image.
0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both of them make it use 100% of CPU also.
Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support.
tested commands:
W2000:
$ qemu -m 256 -localtime -net nic,model=rtl8139 -net tap -usbdevice host:0e21:0750 /var/opt/vm/w2000.img
W2000:
$ qemu /var/opt/vm/w2000.img
OpenBSD 4.8:
$ qemu -cdrom ~/cd48.iso -boot d empty-qcow2.img
tried to use `-M pc-0.12` selector, different audio cards (I've found it caused infinite loop on startup once) -- no luck.
tried to use recent seabios from git -- still no luck.
attached strace log of 0.14.0.
everything was tested on HP mini 311C with Intel Atom N270.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/721793/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 772275] Re: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
From: Thomas Huth @ 2016-11-09 12:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20110428104838.18779.37169.malonedeb@soybean.canonical.com>
Triaging old bug tickets ... can you still reproduce this problem with
the latest version of QEMU and the latest version of the virtio-net
drivers?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/772275
Title:
qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
Status in QEMU:
Incomplete
Bug description:
Hi,
I'm a proxmox distrib user,
I have network error with virtio nic cards in win2008r2sp1 server,
only with qemu 0.14 and 2.6.35 kernel combination.
after some network transferts (can be 2mb or 500mb), nic doesn't
respond anymore. only way is to reboot.
e1000 driver working fine.
revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 +
2.6.32 kernel is working fine too.
i'm using virtio nic drivers 1.1.16 from
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from
https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26
i'm not the only proxmox user ,more users reports here :
http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-
drivers-for-Windows-and-latest-PVE-1.8
i've also see that a slackware user with winxp guest has the same
problem
http://www.spinics.net/lists/kvm/msg51089.html
I can help to debug if it's possible to have logs somewhere .....
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/772275/+subscriptions
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Jike Song @ 2016-11-09 12:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alex Williamson, guangrong.xiao, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <9e83a26f-e5dc-ed91-a1b5-c6f165eed7ed@redhat.com>
On 11/08/2016 04:45 AM, Paolo Bonzini wrote:
> On 07/11/2016 19:28, Alex Williamson wrote:
>>>> Can the reference become invalid?
>>>
>>> No, this is guaranteed by virt/kvm/vfio.c + the udata.lock mutex (which
>>> probably should be renamed...).
>>
>> The caller gets a reference to kvm, but there's no guarantee that the
>> association of that kvm reference to the group stays valid. Once we're
>> outside of that mutex, we might as well consider that kvm:group
>> association stale.
>>
>>>> The caller may still hold
>>>> a kvm references, but couldn't the group be detached from one kvm
>>>> instance and re-attached to another?
>>>
>>> Can this be handled by the vendor driver? Does it get a callback when
>>> it's detached from a KVM instance?
>>
>> The only release callback through vfio is when the user closes the
>> device, the code in this series is the full extent of vfio awareness of
>> kvm. Thanks,
>
> Maybe there should be an mdev callback at the point of association and
> deassociation between VFIO and KVM. Then the vendor driver can just use
> the same mutex for association, deassociation and usage. I'm not even
> sure that these patches are necessary once you have that callback.
Hi Alex & Paolo,
So I cooked another draft version of this, there is no kvm pointer saved
in vfio_group in this version, and notifier will be called on attach/detach,
please kindly have a look :-)
--
Thanks,
Jike
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index ed2361e4..20b5da9 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -34,6 +34,7 @@
#include <linux/uaccess.h>
#include <linux/vfio.h>
#include <linux/wait.h>
+#include <linux/kvm_host.h>
#define DRIVER_VERSION "0.3"
#define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
@@ -86,6 +87,10 @@ struct vfio_group {
struct mutex unbound_lock;
atomic_t opened;
bool noiommu;
+ struct {
+ struct mutex lock;
+ struct blocking_notifier_head notifier;
+ } udata;
};
struct vfio_device {
@@ -333,6 +338,7 @@ static struct vfio_group *vfio_create_group(struct iommu_group *iommu_group)
mutex_init(&group->device_lock);
INIT_LIST_HEAD(&group->unbound_list);
mutex_init(&group->unbound_lock);
+ mutex_init(&group->udata.lock);
atomic_set(&group->container_users, 0);
atomic_set(&group->opened, 0);
group->iommu_group = iommu_group;
@@ -414,10 +420,11 @@ static void vfio_group_release(struct kref *kref)
iommu_group_put(iommu_group);
}
-static void vfio_group_put(struct vfio_group *group)
+void vfio_group_put(struct vfio_group *group)
{
kref_put_mutex(&group->kref, vfio_group_release, &vfio.group_lock);
}
+EXPORT_SYMBOL_GPL(vfio_group_put);
/* Assume group_lock or group reference is held */
static void vfio_group_get(struct vfio_group *group)
@@ -480,7 +487,7 @@ static struct vfio_group *vfio_group_get_from_minor(int minor)
return group;
}
-static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
+struct vfio_group *vfio_group_get_from_dev(struct device *dev)
{
struct iommu_group *iommu_group;
struct vfio_group *group;
@@ -494,6 +501,7 @@ static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
return group;
}
+EXPORT_SYMBOL_GPL(vfio_group_get_from_dev);
/**
* Device objects - create, release, get, put, search
@@ -1745,6 +1753,44 @@ long vfio_external_check_extension(struct vfio_group *group, unsigned long arg)
}
EXPORT_SYMBOL_GPL(vfio_external_check_extension);
+int vfio_group_register_notifier(struct vfio_group *group, struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&group->udata.notifier, nb);
+}
+EXPORT_SYMBOL_GPL(vfio_group_register_notifier);
+
+int vfio_group_unregister_notifier(struct vfio_group *group, struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&group->udata.notifier, nb);
+}
+EXPORT_SYMBOL_GPL(vfio_group_unregister_notifier);
+
+void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *))
+{
+ mutex_lock(&group->udata.lock);
+
+ fn(kvm);
+ blocking_notifier_call_chain(&group->udata.notifier,
+ VFIO_GROUP_NOTIFY_ATTACH_KVM, kvm);
+
+ mutex_unlock(&group->udata.lock);
+}
+EXPORT_SYMBOL_GPL(vfio_group_attach_kvm);
+
+void vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *))
+{
+ mutex_lock(&group->udata.lock);
+
+ blocking_notifier_call_chain(&group->udata.notifier,
+ VFIO_GROUP_NOTIFY_DETACH_KVM, kvm);
+ fn(kvm);
+
+ mutex_unlock(&group->udata.lock);
+}
+EXPORT_SYMBOL_GPL(vfio_group_detach_kvm);
+
/**
* Sub-module support
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 87c9afe..4819a45 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -102,6 +102,21 @@ extern void vfio_unregister_iommu_driver(
extern long vfio_external_check_extension(struct vfio_group *group,
unsigned long arg);
+extern struct vfio_group *vfio_group_get_from_dev(struct device *dev);
+extern void vfio_group_put(struct vfio_group *group);
+
+#define VFIO_GROUP_NOTIFY_ATTACH_KVM 1
+#define VFIO_GROUP_NOTIFY_DETACH_KVM 2
+struct kvm;
+extern void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *));
+extern void vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *));
+extern int vfio_group_register_notifier(struct vfio_group *group,
+ struct notifier_block *nb);
+extern int vfio_group_unregister_notifier(struct vfio_group *group,
+ struct notifier_block *nb);
+
/*
* Sub-module helpers
*/
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 1dd087d..d889b56 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -60,6 +60,32 @@ static void kvm_vfio_group_put_external_user(struct vfio_group *vfio_group)
symbol_put(vfio_group_put_external_user);
}
+static void kvm_vfio_group_attach_kvm(struct vfio_group *group, struct kvm_device *dev)
+{
+ void (*fn)(struct vfio_group *, struct kvm *, void (*fn)(struct kvm *));
+
+ fn = symbol_get(vfio_group_attach_kvm);
+ if (!fn)
+ return;
+
+ fn(group, dev->kvm, kvm_get_kvm);
+
+ symbol_put(vfio_group_attach_kvm);
+}
+
+static void kvm_vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm)
+{
+ void (*fn)(struct vfio_group *, struct kvm *, void (*fn)(struct kvm *));
+
+ fn = symbol_get(vfio_group_detach_kvm);
+ if (!fn)
+ return;
+
+ fn(group, kvm, kvm_put_kvm);
+
+ symbol_put(vfio_group_detach_kvm);
+}
+
static bool kvm_vfio_group_is_coherent(struct vfio_group *vfio_group)
{
long (*fn)(struct vfio_group *, unsigned long);
@@ -155,6 +181,8 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
list_add_tail(&kvg->node, &kv->group_list);
kvg->vfio_group = vfio_group;
+ kvm_vfio_group_attach_kvm(vfio_group, dev);
+
kvm_arch_start_assignment(dev->kvm);
mutex_unlock(&kv->lock);
@@ -196,6 +224,8 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
mutex_unlock(&kv->lock);
+ kvm_vfio_group_detach_kvm(vfio_group, dev->kvm);
+
kvm_vfio_group_put_external_user(vfio_group);
kvm_vfio_update_coherency(dev);
@@ -240,6 +270,7 @@ static void kvm_vfio_destroy(struct kvm_device *dev)
struct kvm_vfio_group *kvg, *tmp;
list_for_each_entry_safe(kvg, tmp, &kv->group_list, node) {
+ kvm_vfio_group_detach_kvm(kvg->vfio_group, dev->kvm);
kvm_vfio_group_put_external_user(kvg->vfio_group);
list_del(&kvg->node);
kfree(kvg);
^ permalink raw reply related
* [xen-unstable test] 102045: tolerable FAIL - PUSHED
From: osstest service owner @ 2016-11-09 12:53 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 16480 bytes --]
flight 102045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102045/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 102008
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102008
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-rtds 9 debian-install fail like 102008
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
build-amd64-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
build-i386-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
xen 8a35a95615b1a64c98c30195f343bc2c58054d9d
Last test of basis 102008 2016-11-07 16:52:13 Z 1 days
Testing same since 102027 2016-11-08 04:30:42 Z 1 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable bcb13635fa503113c981c6ea7423f930c1548452
+ branch=xen-unstable
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xbcb13635fa503113c981c6ea7423f930c1548452 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.xen-unstable
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/xen
+ git push osstest@xenbits.xen.org:/home/xen/git/xen.git bcb13635fa503113c981c6ea7423f930c1548452:refs/heads/master
To osstest@xenbits.xen.org:/home/xen/git/xen.git
8a35a95..bcb1363 bcb13635fa503113c981c6ea7423f930c1548452 -> master
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* hppa qemu and string functions
From: Richard Henderson @ 2016-11-09 12:53 UTC (permalink / raw)
To: linux-parisc; +Cc: GNU C Library
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
Off and on, I've been working on a user-only target of hppa to qemu. It's now
about 95% working. If anyone would like to try it out, it's available at
git://github.com/rth7680/qemu.git tgt-hppa
While implementing the unit-type instructions, I wondered why no one (outside
hp?) had written a version of the string routines utilizing the UXOR insn, with
the SomeByteZero and NoByteZero conditions.
Attached are versions of strlen, strchr and strrchr. They pass simple tests
within my emulator; I'd be interested to know if they pass full glibc testing
on real hardware.
Thanks,
r~
[-- Attachment #2: strlen.S --]
[-- Type: text/plain, Size: 1258 bytes --]
;! HP-PA strlen
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strlen
.balign 16
strlen:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Shifting by 1 gets us 4 insns to play with per entry.
ldo -1(%r26), %r20
depw,z %r20, 30, 2, %r20
blr %r20, %r0
copy %r26, %r28
;! ptr % 4 == 1
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 2
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 3
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 0
;! Main loop. Use the Some Byte Zero unit condition to find
;; a word containing the string terminator.
0: ldw,ma 4(%r26), %r20
uxor,sbz %r0, %r20, %r0
b,n 0b
;! Found, somewhere in with word in %r20. Test each byte in
;! sequence, computing the appopriate offset from %r26 into %r21.
ldo -1(%r26), %r21
extrw,u,<> %r20, 23, 8, %r0
ldo -2(%r26), %r21
extrw,u,<> %r20, 15, 8, %r0
ldo -3(%r26), %r21
extrw,u,<> %r20, 7, 8, %r0
ldo -4(%r26), %r21
bv 0(%r2)
sub %r21, %r28, %r28
;! Found, with no displacement off %r26.
9: bv 0(%r2)
sub %r26, %r28, %r28
.exit
.procend
[-- Attachment #3: strchr.S --]
[-- Type: text/plain, Size: 1791 bytes --]
;! HP-PA strchr
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strchr
.balign 16
strchr:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Multiply by 3, giving us 6 insns per entry to work with.
ldo -1(%r26), %r20
extrw,u %r25, 31, 8, %r25
extrw,u %r20, 31, 2, %r20
shladd,l %r20, 1, %r20, %r20
blr %r20, %r0
copy %r26, %r28
;! ptr % 4 == 1
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 2
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 3
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 0
ldw,ma 4(%r28), %r20
depw %r25, 23, 8, %r25
depw %r25, 15, 16, %r25
;! Main loop. Use the No Byte Zero unit condition to find
;; a word containing C or 0.
0: uxor,nbz %r25, %r20, %r0
b,n 1f
uxor,nbz %r0, %r20, %r0
b,n 1f
b 0b
ldw,ma 4(%r28), %r20
;! Found, somewhere in with word in %r20.
;! Test each byte in sequence.
1: extrw,u %r25, 31, 8, %r25
extrw,u %r20, 7, 8, %r21
ldo -4(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 15, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 23, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 31, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
;! String terminator found before the search character.
9: bv 0(%r2)
ldi 0, %r28
.exit
.procend
[-- Attachment #4: strrchr.S --]
[-- Type: text/plain, Size: 2554 bytes --]
;! HP-PA strrchr
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strrchr
.balign 16
strrchr:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Multiply by 3, giving us 6 insns per entry to work with.
ldo -1(%r26), %r20
extrw,u %r25, 31, 8, %r25
extrw,u %r20, 31, 2, %r20
shladd,l %r20, 1, %r20, %r20
blr %r20, %r0
;! Begin by assuming that C is not present.
ldi 0, %r28
;! ptr % 4 == 1
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 2
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 3
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 0
ldw,ma 4(%r26), %r20
copy %r25, %r24
depw %r24, 23, 8, %r24
depw %r24, 15, 16, %r24
;! Main loop.
0: ;; Test for a NUL terminator within the word and exit if found.
uxor,nbz %r0, %r20, %r0
b,n 1f
;; Test for C within the word. If not found, loop and load the
;; next word in the delay slot. If found, load the next word
;; now anyway, since we know that we havn't seen end-of-string.
copy %r20, %r21
uxor,sbz %r24, %r20, %r0
b 0b
ldw,ma 4(%r26), %r20
;; Found C within the "current" word. Note that it is now in %r21,
;; and the address for the beginning of that word is now -8(%r26),
;; since we have incremented the pointer twice since the load.
extrw,u %r21, 7, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -8(%r26), %r28
extrw,u %r21, 15, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -7(%r26), %r28
extrw,u %r21, 23, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -6(%r26), %r28
extrw,u %r21, 31, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -5(%r26), %r28
b,n 0b
;! Found NUL somewhere in with word in %r20, loaded from -4(%r26).
;! Test each byte in sequence.
1: extrw,u %r20, 7, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -4(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
extrw,u %r20, 15, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -3(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
extrw,u %r20, 23, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -2(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
;; Having checked the others, the last byte must be NUL.
;; Do check for the unusual case of C == NUL.
cmpclr,<> %r25, %r0, %r0
ldo -1(%r26), %r28
bv,n 0(%r2)
.exit
.procend
^ permalink raw reply
* [Qemu-devel] [Bug 881637] Re: QEMU fails to build on OpenBSD/hppa
From: Thomas Huth @ 2016-11-09 12:44 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20111025194609.17756.53947.malonedeb@gac.canonical.com>
Do you still have this problem with the latest version of QEMU and a
more recent version of GCC?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/881637
Title:
QEMU fails to build on OpenBSD/hppa
Status in QEMU:
Incomplete
Bug description:
Trying to build previous QEMU releases as well as git code fails on
OpenBSD/hppa...
cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c
/tmp//ccvNbj1U.s: Assembler messages:
/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776).
/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096).
/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136).
/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612).
/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260).
/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784).
/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636).
/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/881637/+subscriptions
^ permalink raw reply
* disable hugepages
From: Keren Hochman @ 2016-11-09 12:55 UTC (permalink / raw)
To: dev
Hi,
how can I create mempool without hugepages?My application is running on a
pcap file so no huge pages is needed ?
Thanks.
^ permalink raw reply
* [PATCH 1/2] net: mvpp2: don't bring up on MAC address set
From: Baruch Siach @ 2016-11-09 12:56 UTC (permalink / raw)
To: Marcin Wojtas; +Cc: netdev, Thomas Petazzoni, Gregory Clement, Baruch Siach
Current .ndo_set_mac_address implementation brings up the interface when revert
to original address after failure succeeds. Fix this.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Untested; I don't have the hardware.
---
drivers/net/ethernet/marvell/mvpp2.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 60227a3452a4..e427b4706726 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5686,9 +5686,8 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
if (!err)
return 0;
/* Reconfigure parser to accept the original MAC address */
- err = mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- if (err)
- goto error;
+ mvpp2_prs_update_mac_da(dev, dev->dev_addr);
+ goto error;
}
mvpp2_stop_dev(port);
@@ -5698,9 +5697,8 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
goto out_start;
/* Reconfigure parser accept the original MAC address */
- err = mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- if (err)
- goto error;
+ mvpp2_prs_update_mac_da(dev, dev->dev_addr);
+ goto error;
out_start:
mvpp2_start_dev(port);
mvpp2_egress_enable(port);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] net: mvpp2: simplify MAC address set code
From: Baruch Siach @ 2016-11-09 12:56 UTC (permalink / raw)
To: Marcin Wojtas; +Cc: netdev, Thomas Petazzoni, Gregory Clement, Baruch Siach
In-Reply-To: <ff17831771f3575f351c134703d3f153485b01c0.1478696194.git.baruch@tkos.co.il>
Remove duplicated code for handling the !netif_running() case.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Build tested only.
---
drivers/net/ethernet/marvell/mvpp2.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index e427b4706726..64b7f985d517 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5674,32 +5674,28 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
{
struct mvpp2_port *port = netdev_priv(dev);
const struct sockaddr *addr = p;
- int err;
+ int err, restart_dev = 0;
if (!is_valid_ether_addr(addr->sa_data)) {
err = -EADDRNOTAVAIL;
goto error;
}
- if (!netif_running(dev)) {
- err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
- if (!err)
- return 0;
- /* Reconfigure parser to accept the original MAC address */
+ if (netif_running(dev)) {
+ mvpp2_stop_dev(port);
+ restart_dev = 1;
+ }
+
+ err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
+ if (err) {
+ /* Reconfigure parser accept the original MAC address */
mvpp2_prs_update_mac_da(dev, dev->dev_addr);
goto error;
}
- mvpp2_stop_dev(port);
-
- err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
- if (!err)
- goto out_start;
+ if (!restart_dev)
+ return 0;
- /* Reconfigure parser accept the original MAC address */
- mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- goto error;
-out_start:
mvpp2_start_dev(port);
mvpp2_egress_enable(port);
mvpp2_ingress_enable(port);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] skd: fix function prototype
From: Arnd Bergmann @ 2016-11-09 12:55 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, Arnd Bergmann, Johannes Thumshirn, Ming Lin,
linux-kernel
In-Reply-To: <20161109125555.1440353-1-arnd@arndb.de>
Building with W=1 shows a harmless warning for the skd driver:
drivers/block/skd_main.c:2959:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration]
This changes the prototype to the expected formatting.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/block/skd_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index 66146b349229..1e536b97f802 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -2945,8 +2945,8 @@ static void skd_completion_worker(struct work_struct *work)
static void skd_isr_msg_from_dev(struct skd_device *skdev);
-irqreturn_t
-static skd_isr(int irq, void *ptr)
+static irqreturn_t
+skd_isr(int irq, void *ptr)
{
struct skd_device *skdev;
u32 intstat;
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] skd: fix msix error handling
From: Arnd Bergmann @ 2016-11-09 12:55 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, Arnd Bergmann, Mike Christie, Hannes Reinecke,
Ming Lin, linux-kernel
As reported by gcc -Wmaybe-uninitialized, the cleanup path for
skd_acquire_msix tries to free the already allocated msi-x vectors
in reverse order, but the index variable may not have been
used yet:
drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
drivers/block/skd_main.c:3890:8: error: ‘i’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This changes the failure path to skip releasing the interrupts
if we have not started requesting them yet.
Fixes: 180b0ae77d49 ("skd: use pci_alloc_irq_vectors")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/block/skd_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index a58256cd94d7..66146b349229 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -3849,7 +3849,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
if (rc < 0) {
pr_err("(%s): failed to enable MSI-X %d\n",
skd_name(skdev), rc);
- goto msix_out;
+ goto out;
}
skdev->msix_entries = kcalloc(SKD_MAX_MSIX_COUNT,
@@ -3858,7 +3858,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
rc = -ENOMEM;
pr_err("(%s): msix table allocation error\n",
skd_name(skdev));
- goto msix_out;
+ goto out;
}
/* Enable MSI-X vectors for the base queue */
@@ -3889,6 +3889,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
msix_out:
while (--i >= 0)
devm_free_irq(&pdev->dev, pci_irq_vector(pdev, i), skdev);
+out:
kfree(skdev->msix_entries);
skdev->msix_entries = NULL;
return rc;
--
2.9.0
^ permalink raw reply related
* error: package X is already installed
From: Yannick Kiekens @ 2016-11-09 12:57 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Hi all,
I am porting several projects from Jethro to Morty.
Some of those projects give several hundreds of "error: package X is
already installed" during do_populate_sdk stage in Morty.
These projects compiled fine in Jethro.
What can cause these errors?
Mvg
Yannick Kiekens
[-- Attachment #2: Type: text/html, Size: 601 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] cputime: some optimizations and cleanups
From: Frederic Weisbecker @ 2016-11-09 13:01 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: LKML, Ingo Molnar, Peter Zijlstra, Paul Mackerras,
Benjamin Herrenschmidt, Michael Neuling, ppc-dev,
Martin Schwidefsky, Heiko Carstens, linux-s390
In-Reply-To: <1477917389-11341-1-git-send-email-sgruszka@redhat.com>
2016-10-31 12:36 GMT+00:00 Stanislaw Gruszka <sgruszka@redhat.com>:
> Patches remove accounting of utimescaled/stimescaled on architectures
> that do not provide those values (scaled cputimes are equal to normal
> cputimes) what is every architecture except powerpc and s390.
>
> Patches do not change user visible behaviour.
>
> There is very little documentation how scaled cputimes should be
> interpreted and what useful information they provide (at least
> I could not find that). Moreover they are exported to user-space
> only via not commonly used taskstats and delayacct interfaces (i.e.
> interfaces that are not used by standard linux tools AFICT). However
> I assume they can not be removed by whole (i.e. replaced by normal
> utimes/stimes on powerpc and s390).
>
> Stanislaw Gruszka (4):
> cputime/powerpc: remove cputime_last_delta global variable
> cputime/powerpc: remove cputime_to_scaled()
> cputime/powerpc/s390: make scaled cputime arch specific
> cputime: simplify task_cputime()
>
> arch/ia64/kernel/time.c | 4 +-
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/cputime.h | 14 ----
> arch/powerpc/kernel/time.c | 8 +-
> arch/s390/Kconfig | 1 +
> arch/s390/kernel/vtime.c | 9 ++-
> arch/x86/kernel/apm_32.c | 4 +-
> include/asm-generic/cputime_jiffies.h | 1 -
> include/asm-generic/cputime_nsecs.h | 1 -
> include/linux/kernel_stat.h | 4 +-
> include/linux/sched.h | 29 +++++---
> kernel/fork.c | 2 +
> kernel/sched/cputime.c | 124 +++++++++------------------------
> kernel/time/posix-cpu-timers.c | 4 +-
> 14 files changed, 73 insertions(+), 133 deletions(-)
>
Excellent patchset!
Thanks a lot Stanislaw!
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Zhang, Helin @ 2016-11-09 13:01 UTC (permalink / raw)
To: Topel, Bjorn, Ananyev, Konstantin, dev@dpdk.org
Cc: Xu, Qian Q, Yao, Lei A, Wu, Jingjing, thomas.monjalon@6wind.com
In-Reply-To: <b2592ded-badc-5445-526c-d0203b48f592@intel.com>
> -----Original Message-----
> From: Topel, Bjorn
> Sent: Wednesday, November 9, 2016 7:28 PM
> To: Ananyev, Konstantin; dev@dpdk.org; Zhang, Helin
> Cc: Xu, Qian Q; Yao, Lei A; Wu, Jingjing; thomas.monjalon@6wind.com
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping for
> i40evf
>
> >> Correct, so the broader question would be "what is the correct
> >> behavior for an example application, when a port configuration isn't
> >> supported by the hardware?".
> >>
> >> My stand, FWIW, is that igb and ixgbe should have the same semantics
> >> as i40e currently has, i.e. return an error to the user if the port
> >> is mis-configured, NOT changing the setting behind the users back.
> >>
> >
> > Fine by me, but then it means that the fix haw to include changes for
> > all apps plus ixgbe and igb PMDs, correct? :)
>
> Ugh. Correct, I guess. :-)
>
> As for ixgbe and igb - they need a patch changing from silent ignore to
> explicit error. Regarding the apps, I guess all the apps that rely on that
> disabling CRC stripping always work, need some work. Or should all the
> example applications have CRC stripping *enabled* by default? I'd assume
> that all DPDK supported NICs has support for CRC stripping and I guess this is
> the rational for having it on by default for Intel VFs.
>
> In general, for the example applications, if an application relies on a property
> for a port, that the hardware doesn't support -- what would be the desired
> behavior? Or is it implied that the example applications only use a common,
> minimal set of features that are know to be supported by all DPDK supported
> hardware?
>
> Isn't it perfectly valid that some example applications wont run for all
> hardware?
>
> Finally, why doesn't l3fwd have the CRC stripped?
>
>
> Björn
Yes, i40e driver changed a little bit on that according to the review comments
during implementation, comparing to igb and ixgbe.
I'd suggest to re-invesitgate if we can do the similar thing in igb and ixgbe driver.
Any critical issue now? Or just an improvement comments?
Thanks,
Helin
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level
From: Sebastian Frias @ 2016-11-09 13:02 UTC (permalink / raw)
To: Måns Rullgård, Florian Fainelli
Cc: David S. Miller, netdev, LKML, Mason, Andrew Lunn
In-Reply-To: <yw1x1syrjil8.fsf@unicorn.mansr.com>
On 11/04/2016 05:49 PM, Måns Rullgård wrote:
>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers
>>> will apply the delay.
>>>
>>> I think a better way of dealing with this is that both, PHY and MAC
>>> drivers exchange information so that the delay is applied only once.
>>
>> Exchange what information? The PHY device interface (phydev->interface)
>> conveys the needed information for both entities.
>
> There doesn't seem to be any consensus among the drivers regarding where
> the delay should be applied. Since only a few drivers, MAC or PHY, act
> on this property, most combinations still work by chance. It is common
> for boards to set the delay at the PHY using external config pins so no
> software setup is required (although I have one Sigma based board that
> gets this wrong). I suspect if drivers/net/ethernet/broadcom/genet were
> used with one of the four PHY drivers that also set the delay based on
> this DT property, things would go wrong.
>
Exactly, what about a patch like (I can make a formal submission, even
merge it with the patch discussed in this thread, consider this a RFC):
diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
index fba2699..4217ff4 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -1283,6 +1283,10 @@ static int nb8800_tangox_init(struct net_device *dev)
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
pad_mode = PAD_MODE_RGMII;
+
+ if ((dev->phydev->flags & PHY_SUPPORTS_TXID) == 0)
+ pad_mode |= PAD_MODE_GTX_CLK_DELAY;
+
break;
default:
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 2e0c759..5eddb04 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -426,7 +426,9 @@ static int at803x_aneg_done(struct phy_device *phydev)
.suspend = at803x_suspend,
.resume = at803x_resume,
.features = PHY_GBIT_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
+ .flags = PHY_HAS_INTERRUPT |
+ PHY_SUPPORTS_RXID |
+ PHY_SUPPORTS_TXID,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = at803x_ack_interrupt,
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e7e1fd3..0f0b17e 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -61,6 +61,8 @@
#define PHY_HAS_INTERRUPT 0x00000001
#define PHY_HAS_MAGICANEG 0x00000002
#define PHY_IS_INTERNAL 0x00000004
+#define PHY_SUPPORTS_RXID 0x00000008
+#define PHY_SUPPORTS_TXID 0x00000010
#define MDIO_DEVICE_IS_PHY 0x80000000
/* Interface Mode definitions */
^ permalink raw reply related
* [RFC] [PATCH] Mounting "degraded,rw" should allow for any number of devices missing
From: Roman Mamedov @ 2016-11-09 13:03 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org
Hello,
Mounting "degraded,rw" should allow for any number of devices missing, as in
many cases the current check seems overly strict and not helpful during what
is already a manual recovery scenario. Let's assume the user applying the
"degraded" option knows best what condition their FS is in and what are the
next steps required to recover from the degraded state.
Specifically this would allow salvaging "JBOD-style" arrays of data=single
metadata=RAID1, if the user is ready to accept loss of data portions which
were on the removed drive. Currently if one of the disks got removed it is not
possible for such array to be mounted rw at all -- hence not possible to
"dev delete missing" and the only solution is to recreate the FS.
Besides, I am currently testing a concept of SSD+HDD array with data=single
and metadata=RAID1, where the SSD is used for RAID1 metadata chunks only.
E.g. my 13 TB FS only has about 14 GB of metadata at the moment, so I could
comfortably use a spare 60GB SSD as a metadata-only device for it.
(Making all metadata reads prefer SSD could be the next step.)
It would be nice to be able to just lose/fail/forget that SSD, without having
to redo the entire FS. But again, since the remaining device has data=single,
currently it won't be write-mountable in the degraded state, even though the
missing device had only ever contained RAID1 chunks.
Maybe someone has other ideas how to solve the above scenarios?
Thanks
--- linux-amd64-4.4/fs/btrfs/disk-io.c.orig 2016-11-09 16:19:50.431117913 +0500
+++ linux-amd64-4.4/fs/btrfs/disk-io.c 2016-11-09 16:20:31.567117874 +0500
@@ -2992,7 +2992,8 @@
btrfs_calc_num_tolerated_disk_barrier_failures(fs_info);
if (fs_info->fs_devices->missing_devices >
fs_info->num_tolerated_disk_barrier_failures &&
- !(sb->s_flags & MS_RDONLY)) {
+ !(sb->s_flags & MS_RDONLY) &&
+ !btrfs_raw_test_opt(fs_info->mount_opt, DEGRADED)) {
pr_warn("BTRFS: missing devices(%llu) exceeds the limit(%d), writeable mount is not allowed\n",
fs_info->fs_devices->missing_devices,
fs_info->num_tolerated_disk_barrier_failures);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.