Re: device compatibility interface for live migration with assigned devices
On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote: > > On 2020/8/10 下午3:46, Yan Zhao wrote: > > > driver is it handled by? > > It looks that the devlink is for network device specific, and in > > devlink.h, it says > > include/uapi/linux/devlink.h - Network physical device Netlink > > interface, > > > Actually not, I think there used to have some discussion last year and the > conclusion is to remove this comment. > > It supports IB and probably vDPA in the future. > hmm... sorry, I didn't find the referred discussion. only below discussion regarding to why to add devlink. https://www.mail-archive.com/netdev@vger.kernel.org/msg95801.html >This doesn't seem to be too much related to networking? Why can't something >like this be in sysfs? It is related to networking quite bit. There has been couple of iteration of this, including sysfs and configfs implementations. There has been a consensus reached that this should be done by netlink. I believe netlink is really the best for this purpose. Sysfs is not a good idea https://www.mail-archive.com/netdev@vger.kernel.org/msg96102.html >there is already a way to change eth/ib via >echo 'eth' > /sys/bus/pci/drivers/mlx4_core/:02:00.0/mlx4_port1 > >sounds like this is another way to achieve the same? It is. However the current way is driver-specific, not correct. For mlx5, we need the same, it cannot be done in this way. Do devlink is the correct way to go. https://lwn.net/Articles/674867/ There a is need for some userspace API that would allow to expose things that are not directly related to any device class like net_device of ib_device, but rather chip-wide/switch-ASIC-wide stuff. Use cases: 1) get/set of port type (Ethernet/InfiniBand) 2) monitoring of hardware messages to and from chip 3) setting up port splitters - split port into multiple ones and squash again, enables usage of splitter cable 4) setting up shared buffers - shared among multiple ports within one chip we actually can also retrieve the same information through sysfs, .e.g |- [path to device] |--- migration | |--- self | | |---device_api | | |---mdev_type | | |---software_version | | |---device_id | | |---aggregator | |--- compatible | | |---device_api | | |---mdev_type | | |---software_version | | |---device_id | | |---aggregator > > > I feel like it's not very appropriate for a GPU driver to use > > this interface. Is that right? > > > I think not though most of the users are switch or ethernet devices. It > doesn't prevent you from inventing new abstractions. so need to patch devlink core and the userspace devlink tool? e.g. devlink migration > Note that devlink is based on netlink, netlink has been widely used by > various subsystems other than networking. the advantage of netlink I see is that it can monitor device status and notify upper layer that migration database needs to get updated. But not sure whether openstack would like to use this capability. As Sean said, it's heavy for openstack. it's heavy for vendor driver as well :) And devlink monitor now listens the notification and dumps the state changes. If we want to use it, need to let it forward the notification and dumped info to openstack, right? Thanks Yan
Re: device compatibility interface for live migration with assigned devices
On 8/13/20 11:33 AM, Cornelia Huck wrote: > On Fri, 7 Aug 2020 13:59:42 +0200 > Cornelia Huck wrote: > >> On Wed, 05 Aug 2020 12:35:01 +0100 >> Sean Mooney wrote: >> >>> On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote: Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.z...@intel.com wrote: >> >> (...) >> >software_version: device driver's version. > in .[.bugfix] scheme, where there is no > compatibility across major versions, minor versions have > forward compatibility (ex. 1-> 2 is ok, 2 -> 1 is not) and > bugfix version number indicates some degree of internal > improvement that is not visible to the user in terms of > features or compatibility, > > vendor specific attributes: each vendor may define different attributes > device id : device id of a physical devices or mdev's parent pci device. > it could be equal to pci id for pci devices > aggregator: used together with mdev_type. e.g. aggregator=2 together > with i915-GVTg_V5_4 means 2*1/4=1/2 of a gen9 Intel > graphics device. > remote_url: for a local NVMe VF, it may be configured with a remote > url of a remote storage and all data is stored in the > remote side specified by the remote url. > ... >>> just a minor not that i find ^ much more simmple to understand then >>> the current proposal with self and compatiable. >>> if i have well defiend attibute that i can parse and understand that allow >>> me to calulate the what is and is not compatible that is likely going to >>> more useful as you wont have to keep maintianing a list of other compatible >>> devices every time a new sku is released. >>> >>> in anycase thank for actully shareing ^ as it make it simpler to reson >>> about what >>> you have previously proposed. >> >> So, what would be the most helpful format? A 'software_version' field >> that follows the conventions outlined above, and other (possibly >> optional) fields that have to match? > > Just to get a different perspective, I've been trying to come up with > what would be useful for a very different kind of device, namely > vfio-ccw. (Adding Eric to cc: for that.) > > software_version makes sense for everybody, so it should be a standard > attribute. > > For the vfio-ccw type, we have only one vendor driver (vfio-ccw_IO). > > Given a subchannel A, we want to make sure that subchannel B has a > reasonable chance of being compatible. I guess that means: > > - same subchannel type (I/O) > - same chpid type (e.g. all FICON; I assume there are no 'mixed' setups > -- Eric?) Correct. > - same number of chpids? Maybe we can live without that and just inject > some machine checks, I don't know. Same chpid numbers is something we > cannot guarantee, especially if we want to migrate cross-CEC (to > another machine.) I think we'd live without it, because I wouldn't expect it to be consistent between systems. > > Other possibly interesting information is not available at the > subchannel level (vfio-ccw is a subchannel driver.) I presume you're alluding to the DASD uid (dasdinfo -x) here? > > So, looking at a concrete subchannel on one of my machines, it would > look something like the following: > > > software_version=1.0.0 > type=vfio-ccw <-- would be vfio-pci on the example above > > subchannel_type=0 > > chpid_type=0x1a > chpid_mask=0xf0<-- not sure if needed/wanted > > Does that make sense? >
Re: [PATCH v2] virnetserver: fix some memory leaks in virNetTLSContextReloadForServer
On 8/13/20 12:37 AM, Jin Yan wrote:
These leaks were introduced in commit 15d280fa97b0, use g_autofree for all
cert_path pointers.
Signed-off-by: Jin Yan
---
Reviewed-by: Daniel Henrique Barboza
src/rpc/virnettlscontext.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/rpc/virnettlscontext.c b/src/rpc/virnettlscontext.c
index 168f3010ae..37564db14e 100644
--- a/src/rpc/virnettlscontext.c
+++ b/src/rpc/virnettlscontext.c
@@ -921,10 +921,10 @@ int virNetTLSContextReloadForServer(virNetTLSContextPtr
ctxt,
{
gnutls_certificate_credentials_t x509credBak;
int err;
-char *cacert = NULL;
-char *cacrl = NULL;
-char *cert = NULL;
-char *key = NULL;
+g_autofree char *cacert = NULL;
+g_autofree char *cacrl = NULL;
+g_autofree char *cert = NULL;
+g_autofree char *key = NULL;
x509credBak = ctxt->x509cred;
ctxt->x509cred = NULL;
Re: [PATCH v2 10/13] qemu: avoid deadlock in qemuDomainObjStopWorker
On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote:
We are dropping the only reference here so that the event loop thread
is going to be exited synchronously. In order to avoid deadlocks we
need to unlock the VM so that any handler being called can finish
execution and thus even loop thread be finished too.
Signed-off-by: Nikolay Shirokovskiy
---
Reviewed-by: Daniel Henrique Barboza
src/qemu/qemu_domain.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 5b22eb2..82b3d11 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1637,11 +1637,21 @@ void
qemuDomainObjStopWorker(virDomainObjPtr dom)
{
qemuDomainObjPrivatePtr priv = dom->privateData;
+virEventThread *eventThread;
-if (priv->eventThread) {
-g_object_unref(priv->eventThread);
-priv->eventThread = NULL;
-}
+if (!priv->eventThread)
+return;
+
+/*
+ * We are dropping the only reference here so that the event loop thread
+ * is going to be exited synchronously. In order to avoid deadlocks we
+ * need to unlock the VM so that any handler being called can finish
+ * execution and thus even loop thread be finished too.
+ */
+eventThread = g_steal_pointer(&priv->eventThread);
+virObjectUnlock(dom);
+g_object_unref(eventThread);
+virObjectLock(dom);
}
Re: [PATCH v2 10/13] qemu: avoid deadlock in qemuDomainObjStopWorker
On 8/11/20 3:39 AM, Nikolay Shirokovskiy wrote: On 10.08.2020 20:40, Daniel Henrique Barboza wrote: On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote: We are dropping the only reference here so that the event loop thread is going to be exited synchronously. In order to avoid deadlocks we need to unlock the VM so that any handler being called can finish execution and thus even loop thread be finished too. Given that this code only makes sense when called from qemuDomainObjStopWorkerIter(), I'd suggest removing the lock/unlock of this function (turning it into just a call to qemuDomainObjStopWorker()) and move them inside the body of qemuDomainObjStopWorker(), locking and unlocking the mutex inside the scope of the same function. Hi, Daniel. Actually all callers of qemuProcessStop hold the lock. Moreover they even hold job condition. And calling qemuProcessStop without lock/job condition would be a mistake AFIU (qemuConnectDomainXMLToNative is the only exception I see that holds the lock but not the job condition. But this function creates new vm object that is not shared with other threads) I understand you concern but there are precedents. Take a look for example virDomainObjListRemove. The lock requirements are documented for virDomainObjListRemove and I can do it for qemuDomainObjStopWorker too but it looks a bit over documenting to me. Got it. Thanks for explaining. Nikolay
Re: device compatibility interface for live migration with assigned devices
On Fri, 7 Aug 2020 13:59:42 +0200 Cornelia Huck wrote: > On Wed, 05 Aug 2020 12:35:01 +0100 > Sean Mooney wrote: > > > On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote: > > > Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.z...@intel.com wrote: > > (...) > > > > >software_version: device driver's version. > > > > in .[.bugfix] scheme, where there is no > > > >compatibility across major versions, minor versions have > > > >forward compatibility (ex. 1-> 2 is ok, 2 -> 1 is not) > > > > and > > > >bugfix version number indicates some degree of internal > > > >improvement that is not visible to the user in terms of > > > >features or compatibility, > > > > > > > > vendor specific attributes: each vendor may define different attributes > > > > device id : device id of a physical devices or mdev's parent pci > > > > device. > > > > it could be equal to pci id for pci devices > > > > aggregator: used together with mdev_type. e.g. aggregator=2 together > > > > with i915-GVTg_V5_4 means 2*1/4=1/2 of a gen9 Intel > > > >graphics device. > > > > remote_url: for a local NVMe VF, it may be configured with a remote > > > > url of a remote storage and all data is stored in the > > > >remote side specified by the remote url. > > > > ... > > just a minor not that i find ^ much more simmple to understand then > > the current proposal with self and compatiable. > > if i have well defiend attibute that i can parse and understand that allow > > me to calulate the what is and is not compatible that is likely going to > > more useful as you wont have to keep maintianing a list of other compatible > > devices every time a new sku is released. > > > > in anycase thank for actully shareing ^ as it make it simpler to reson > > about what > > you have previously proposed. > > So, what would be the most helpful format? A 'software_version' field > that follows the conventions outlined above, and other (possibly > optional) fields that have to match? Just to get a different perspective, I've been trying to come up with what would be useful for a very different kind of device, namely vfio-ccw. (Adding Eric to cc: for that.) software_version makes sense for everybody, so it should be a standard attribute. For the vfio-ccw type, we have only one vendor driver (vfio-ccw_IO). Given a subchannel A, we want to make sure that subchannel B has a reasonable chance of being compatible. I guess that means: - same subchannel type (I/O) - same chpid type (e.g. all FICON; I assume there are no 'mixed' setups -- Eric?) - same number of chpids? Maybe we can live without that and just inject some machine checks, I don't know. Same chpid numbers is something we cannot guarantee, especially if we want to migrate cross-CEC (to another machine.) Other possibly interesting information is not available at the subchannel level (vfio-ccw is a subchannel driver.) So, looking at a concrete subchannel on one of my machines, it would look something like the following: software_version=1.0.0 type=vfio-ccw <-- would be vfio-pci on the example above subchannel_type=0 chpid_type=0x1a chpid_mask=0xf0<-- not sure if needed/wanted Does that make sense?
[PATCH 1/3] qemu: avoid maybe-uninitialized warning by GCC 10
GCC 10 complains about "well_formed_uri" may be used uninitialzed.
Even though it is a false positive, we can easily avoid it.
Avoiding
../src/qemu/qemu_migration.c: In function ‘qemuMigrationDstPrepareDirect’:
../src/qemu/qemu_migration.c:2920:16: error: ‘well_formed_uri’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2920 | if (well_formed_uri) {
|^
Signed-off-by: Boris Fiuczynski
Reviewed-by: Marc Hartmayer
---
src/qemu/qemu_migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 0f2f92b211..142faa2cf9 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2886,7 +2886,7 @@ qemuMigrationDstPrepareDirect(virQEMUDriverPtr driver,
*uri_out = g_strdup_printf(incFormat, "tcp", hostname, port);
} else {
-bool well_formed_uri;
+bool well_formed_uri = false;
if (!(uri = qemuMigrationAnyParseURI(uri_in, &well_formed_uri)))
goto cleanup;
--
2.25.1
[PATCH 0/3] Avoid some GCC 10 warnings
Caught these when switching to F32 using GCC v10.2.1 on s390x. Boris Fiuczynski (3): qemu: avoid maybe-uninitialized warning by GCC 10 tools: avoid potential null pointer dereference by GCC 10 storage: avoid maybe-uninitialized warning by GCC 10 src/qemu/qemu_migration.c | 2 +- src/storage/storage_backend_iscsi_direct.c | 8 tools/vsh.c| 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) -- 2.25.1
[PATCH 2/3] tools: avoid potential null pointer dereference by GCC 10
GCC 10 complains about "arg" possibly being a NULL dereference.
Even though it might be a false positive, we can easily avoid it.
Avoiding
../tools/vsh.c: In function ‘vshCommandOptStringReq’:
../tools/vsh.c:1034:19: error: potential null pointer dereference
[-Werror=null-dereference]
1034 | else if (!*arg->data && !(arg->def->flags & VSH_OFLAG_EMPTY_OK))
|~~~^~
Signed-off-by: Boris Fiuczynski
Reviewed-by: Marc Hartmayer
---
tools/vsh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/vsh.c b/tools/vsh.c
index 5e2e3ac219..11f493f969 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -1031,7 +1031,7 @@ vshCommandOptStringReq(vshControl *ctl,
/* this should not be propagated here, just to be sure */
if (ret == -1)
error = N_("Mandatory option not present");
-else if (!*arg->data && !(arg->def->flags & VSH_OFLAG_EMPTY_OK))
+else if (arg && !*arg->data && !(arg->def->flags & VSH_OFLAG_EMPTY_OK))
error = N_("Option argument is empty");
if (error) {
--
2.25.1
[PATCH 3/3] storage: avoid maybe-uninitialized warning by GCC 10
GCC 10 complains about variables may be used uninitialized.
Even though it might be false positives, we can easily avoid them.
Avoiding
../src/storage/storage_backend_iscsi_direct.c:634:11: error: ‘nb_block’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
634 | while (lba < nb_block) {
| ^
../src/storage/storage_backend_iscsi_direct.c:619:14: note: ‘nb_block’ was
declared here
619 | uint64_t nb_block;
| ^~~~
../src/storage/storage_backend_iscsi_direct.c:637:16: error: ‘block_size’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
637 | task = iscsi_write16_sync(iscsi, lun, lba, data,
|^
638 | block_size * to_write,
| ~~
639 | block_size, 0, 0, 0, 0, 0);
| ~~
../src/storage/storage_backend_iscsi_direct.c:618:14: note: ‘block_size’ was
declared here
618 | uint32_t block_size;
| ^~
../src/storage/storage_backend_iscsi_direct.c: In function
‘virStorageBackendISCSIDirectRefreshPool’:
../src/storage/storage_backend_iscsi_direct.c:320:39: error: ‘nb_block’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
320 | vol->target.capacity = block_size * nb_block;
|~~~^~
../src/storage/storage_backend_iscsi_direct.c:306:14: note: ‘nb_block’ was
declared here
306 | uint64_t nb_block;
| ^~~~
../src/storage/storage_backend_iscsi_direct.c:320:39: error: ‘block_size’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
320 | vol->target.capacity = block_size * nb_block;
|~~~^~
../src/storage/storage_backend_iscsi_direct.c:305:14: note: ‘block_size’ was
declared here
305 | uint32_t block_size;
| ^~
Signed-off-by: Boris Fiuczynski
Reviewed-by: Marc Hartmayer
---
src/storage/storage_backend_iscsi_direct.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/storage/storage_backend_iscsi_direct.c
b/src/storage/storage_backend_iscsi_direct.c
index c37c671db6..027fa83de7 100644
--- a/src/storage/storage_backend_iscsi_direct.c
+++ b/src/storage/storage_backend_iscsi_direct.c
@@ -302,8 +302,8 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
char *portal)
{
virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
-uint32_t block_size;
-uint64_t nb_block;
+uint32_t block_size = 0;
+uint64_t nb_block = 0;
g_autoptr(virStorageVolDef) vol = NULL;
if (virISCSIDirectTestUnitReady(iscsi, lun) < 0)
@@ -615,8 +615,8 @@ virStorageBackendISCSIDirectVolWipeZero(virStorageVolDefPtr
vol,
struct iscsi_context *iscsi)
{
uint64_t lba = 0;
-uint32_t block_size;
-uint64_t nb_block;
+uint32_t block_size = 0;
+uint64_t nb_block = 0;
struct scsi_task *task = NULL;
int lun = 0;
int ret = -1;
--
2.25.1
Re: [PATCH 0/3] batch: don't require checking retvalue of some bitmap ops
On 30.07.2020 18:49, Nikolay Shirokovskiy wrote: > > > On 30.07.2020 17:56, Peter Krempa wrote: >> On Thu, Jul 30, 2020 at 17:27:35 +0300, Nikolay Shirokovskiy wrote: >>> Most of bitmap setBit/clearBit/getBit users know that the bitmap index is >>> not out of bound and thus don't check the return value. More precisely >>> the stats is next: >>> >>> Methodall check >>> === >>> virBitmapSetBit85 14 >>> virBitmapClearBit 15 3 >>> virBitmapGetBit15 6 >>> >>> where 'all' is the number of all occurences of the method and 'check' is the >>> number of occurences with 'if (method' pattern. >>> >>> Thus keeping the retvalue checking requirement produces more >>> noise then helps. I guess we even can make these function return >>> void as users can simply compare the index with the bitmap size. >> >> Well. An ignore_value is not really expensive and it makes the callers >> aware that something needs to be checked. > > The only condition these methods can fail is out of bound. Most of > time it is known by the caller that there is no out of bound condition. > So when compiler suggests to check error I personally go and read > the code only to found it can not fail in my circumstances. > At the same time it is quite obvious that these function can not > produce something meaningful for out of bound. That's why > I even thinking of why don't make these methods return void. > >> >> I don't really see the point of this. >> >> Additionally, individual patches are missing justification in the commit >> message. Mentioning it in the cover letter is not enough as that doesn't >> get comitted. >> > > I thought that writing same justification 3 times in a row will be > too much. At the same time writing some short version will not explain > things thoroughly. May be I should add good explanation only > to the first patch. > Hi, everyone. Is there other opinions on the topic or I can forget about the series and let it go?) Nikolay
Re: [PATCH 1/2] apparmor: allow adding permanent per guest rules
On Fri, Aug 7, 2020 at 6:14 PM Daniel P. Berrangé wrote: > On Fri, Aug 07, 2020 at 12:21:19PM +0200, Christian Ehrhardt wrote: > > The design of apparmor in libvirt always had a way to define custom > > per-guest rules as described in docs/drvqemu.html and [1]. > > > > A fix meant to clean the profiles after guest shutdown was a bit > > overzealous and accidentially removed this important admin feature as > > well. > > > > Therefore reduce the --delete option of virt-aa-helper to only delete > > the .files that would be re-generated in any case. > > > > Users/Admins are always free to clean the profiles themselve if they > > prefer a clean directory - they will be regenerated as needed. But > > libvirt should never remove the base profile meant to allow per-guest > > overrides and thereby break a documented feature. > > > > [1]: https://gitlab.com/apparmor/apparmor/-/wikis/Libvirt#advanced-usage > > > > Fixes: eba2225b "apparmor: delete profile on VM shutdown" > > > > Signed-off-by: Christian Ehrhardt > > --- > > src/security/virt-aa-helper.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Reviewed-by: Daniel P. Berrangé > (as with the other recent apparmor patch patch) Thanks for the review - there was no negative feedback so far and in tests this worked fine. I'm committing the changes to not be postponed to close to the next release. > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Re: [PATCH 2/2] apparmor: allow unmounting .dev entries
On Fri, Aug 7, 2020 at 6:14 PM Daniel P. Berrangé wrote: > On Fri, Aug 07, 2020 at 12:21:20PM +0200, Christian Ehrhardt wrote: > > With qemu 5.0 and libvirt 6.6 there are new apparmor denials: > > apparmor="DENIED" operation="umount" profile="libvirtd" > > name="/run/libvirt/qemu/1-kvmguest-groovy-norm.dev/" comm="rpc-worker" > > > > These are related to new issues around devmapper handling [1] and the > > error path triggered by these issues now causes this new denial. > > > > There are already related rules for mounting and it seems right to > > allow also the related umount. > > > > [1]: > https://www.redhat.com/archives/libvir-list/2020-August/msg00236.html > > > > Signed-off-by: Christian Ehrhardt > > --- > > src/security/apparmor/usr.sbin.libvirtd.in | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Daniel P. Berrangé > Thanks for the review - there was no negative feedback so far and in tests this worked fine. I'm committing the changes to not be postponed to close to the next release. > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Plans for the next release
I'm sending this quite early this month as I'm on vacation tomorrow and next week and I wanted to make sure the plan for the release is advertised earlier than just a day or two before the freeze. To aim for the release on Sep 01 I suggest entering the freeze in two weeks on Wednesday Aug 26 and tagging RC2 on Friday Aug 28 in the afternoon. I hope this works for everyone. Jirka
