On 28.03.2012 22:32, Josh Triplett wrote:
Enable x86 feature-based autoloading for the kvm-amd module on CPUs
with X86_FEATURE_SVM.
Signed-off-by: Josh Triplett j...@joshtriplett.org
It appears to work fine on my amd boxen. The only problem
is that I've no idea when it will be possible to
On Thu, Mar 29, 2012 at 10:33:25AM +0400, Michael Tokarev wrote:
On 28.03.2012 22:32, Josh Triplett wrote:
Enable x86 feature-based autoloading for the kvm-amd module on CPUs
with X86_FEATURE_SVM.
Signed-off-by: Josh Triplett j...@joshtriplett.org
It appears to work fine on my amd
On 03/28/2012 10:32 PM, Vivek Goyal wrote:
If a virtio disk is open in guest and a disk resize operation is done,
(virsh blockresize), new size is not visible to tools like fdisk -l.
This seems to be happening as we update only part-nr_sects and not
bdev-bd_inode size.
Call
Hi everyone!
We have an Hylafax 5.2.5 CentOS 5 installation hosted inside a Xen
virtual machine. It works quite well, but now I'm in the process of
upgrading/migrating it to a KVM virtual machine running Ubuntu 10.04.
The problem I'm having is that - while receiving works fine - sending
Expand boundaries of some tests since it was observed that on some cpus
results do not fit.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/x86/pmu.c b/x86/pmu.c
index e1b8279..2c46f31 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -80,8 +80,8 @@ struct pmu_event {
} gp_events[] = {
* Idea
The present bit of page fault error code (EFEC.P) indicates whether the
page table is populated on all levels, if this bit is set, we can know
the page fault is caused by the page-protection bits (e.g. W/R bit) or
the reserved bits.
In KVM, in most cases, all this kind of page fault
Only test present bit is not enough since mmio spte is also set this bit,
use is_rmap_spte() instead of it
Also move the BUG_ONs to the common function to cleanup the code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 12 ++--
1 files changed,
Introduce a common function to abstract spte write-protect to cleanup the
code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 57 ++-
1 files changed, 33 insertions(+), 24 deletions(-)
diff --git
Split FNAME(prefetch_invalid_gpte) to check gpte independently which will
be used in the later patch
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/paging_tmpl.h | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git
It can calculate the base gpa of the specified shadow page on any level,
let it instead of FNAME(get_level1_sp_gpa)
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/paging_tmpl.h | 26 --
1 files changed, 12 insertions(+), 14 deletions(-)
Do not use the last byte (bit 56 ~ bit 63) in shadow_mmio_mask, the late
patch will store vcpu id in the last byte
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |1 +
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
3 files changed, 3
Export the present bit of page fault error code, the later patch will
use it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/vmx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
In current code, only one bit (bit 0) is used in rmap, this patch export
more bits from rmap, during pte add/remove, it only touches bit 0 and other
bits are keeped
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 143
Using PTE_LIST_WRITE_PROTECT bit in rmap store the write-protect status to
avoid unnecessary shadow page walking
Also if no shadow page is indirect, the page is write-free
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 34
It depends on PTE_LIST_WRITE_PROTECT bit in rmap which let us quickly know
whether the page is writable out of mmu-lock
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 17 +
arch/x86/kvm/paging_tmpl.h |2 +-
2 files changed,
The last byte of spte can be modified freely since cpu does not touch it
and no pfn mapping is in the area, but NX bit (if it exists) is in this
area, we always set it to reduce access
On the PAE shadow mode, vcpu id spte can cause the #PF with RSV = 1, it will
be treated as a mmio spte, we need
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is only
modify the access bit which can be done out of mmu-lock
The tricks in this patch is avoiding the race between fast page fault
path and write-protect path,
To see what happen on this path and help us to optimize it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |2 ++
arch/x86/kvm/mmutrace.h | 43 +++
2 files changed, 45 insertions(+), 0 deletions(-)
diff
The P bit of page fault error code is missed in this tracepoint, fix it
by passing the full error code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmutrace.h|7 +++
arch/x86/kvm/paging_tmpl.h |3 +--
2 files changed, 4 insertions(+), 6
On 03/28/2012 07:44 PM, Michal Suchanek wrote:
Hello,
On 28 March 2012 19:02, Avi Kivity a...@redhat.com wrote:
0:0f 2b 07 movntps %xmm0,(%edi)
3:0f 2b 4f 10 movntps %xmm1,0x10(%edi)
7:0f 2b 57 20 movntps %xmm2,0x20(%edi)
On 03/28/2012 11:04 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote:
Ah, then it's not a guest problem, it's how the chip was designed.
Newer chips do allow a workaround (GR31 bit 6):
6 System Source Location (Revision A): If this bit is ‘1’, the
On 03/29/2012 07:15 AM, Takuya Yoshikawa wrote:
On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity a...@redhat.com wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
Looks like a good baseline on which to build the KVM
implementation. We
might need some handshake to prevent interference on the host
side with
the PLE code.
I think I still missed some point in
On 03/29/2012 11:20 AM, Xiao Guangrong wrote:
* Idea
The present bit of page fault error code (EFEC.P) indicates whether the
page table is populated on all levels, if this bit is set, we can know
the page fault is caused by the page-protection bits (e.g. W/R bit) or
the reserved bits.
In
On 03/28/2012 11:57 PM, Rusty Russell wrote:
Should this code be dropped altogether? Peter points out that once we
add new regs, they *must* be initialized to correct reset values in case
older QEMU knows nothing about them, but for the rest it just seems
confusing...
It's
On 03/29/2012 11:21 AM, Xiao Guangrong wrote:
Introduce a common function to abstract spte write-protect to cleanup the
code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 57 ++-
1 files changed, 33
On 03/29/2012 06:18 PM, Avi Kivity wrote:
On 03/29/2012 11:20 AM, Xiao Guangrong wrote:
* Idea
The present bit of page fault error code (EFEC.P) indicates whether the
page table is populated on all levels, if this bit is set, we can know
the page fault is caused by the page-protection bits
On Thu, 2012-03-29 at 11:36 +0200, Avi Kivity wrote:
In any case, X seems to avoid it, maybe nobody does color expansion
nowadays (I suppose modern desktops don't, maybe using ancient X apps
might trigger that path). So no biggie. I'll have to fix KVM powerpc
dealing with memslot changes
On 03/29/2012 07:11 PM, Avi Kivity wrote:
+/* Return true if the spte is dropped. */
+static bool spte_write_protect(struct kvm *kvm, u64 *sptep, bool large,
+ int *flush)
bool *flush
Okay, will fix.
+{
+u64 spte = *sptep;
+
+if
On 2012-03-27 18:39, Anthony Liguori wrote:
On 03/27/2012 11:22 AM, Jan Kiszka wrote:
On 2012-03-27 17:59, Avi Kivity wrote:
On 03/27/2012 11:55 AM, Jan Kiszka wrote:
On 2012-03-27 10:55, Vasilis Liaskovitis wrote:
Hi,
is live migration between qemu-kvm stable-0.15 and stable-1.0 trees
On 03/29/2012 07:36 AM, Ren Mingxin wrote:
On 03/28/2012 06:58 PM, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote:
Hi,
The current virtblk's naming algorithm just supports 26^3
disks. If there are mass of virtblks(exceeding 26^3), there
will be
On Thu, Mar 29, 2012 at 02:03:55PM +0200, Jens Axboe wrote:
On 03/29/2012 07:36 AM, Ren Mingxin wrote:
On 03/28/2012 06:58 PM, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote:
Hi,
The current virtblk's naming algorithm just supports 26^3
disks.
On 03/29/2012 01:40 PM, Xiao Guangrong wrote:
* Implementation
We can freely walk the page between walk_shadow_page_lockless_begin and
walk_shadow_page_lockless_end, it can ensure all the shadow page is valid.
In the most case, cmpxchg is fair enough to change the access bit of spte,
On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
Split FNAME(prefetch_invalid_gpte) to check gpte independently which will
be used in the later patch
-static bool FNAME(prefetch_invalid_gpte)(struct kvm_vcpu *vcpu,
- struct kvm_mmu_page *sp, u64 *spte,
-
On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
It can calculate the base gpa of the specified shadow page on any level,
let it instead of FNAME(get_level1_sp_gpa)
+static gpa_t FNAME(get_sp_gpa)(struct kvm_mmu_page *sp)
+{
Maybe worth adding a pte index and calling it get_spte_gpa(), depends
On 03/29/2012 11:23 AM, Xiao Guangrong wrote:
Do not use the last byte (bit 56 ~ bit 63) in shadow_mmio_mask, the late
patch will store vcpu id in the last byte
Bit 63 is PT64_NX_MASK.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the
Hi,
As a workaround you can use -vga std or -vga qxl. The latter will work
even better when we have a kernel driver.
There is a kernel driver for -vga std too ;)
http://patchwork.ozlabs.org/patch/145479/
Didn't try on ppc though. There is a funky #ifdef TARGET_I386 in
vbe_portio_list[],
Hello,
RHEL 6.2 had a technology evaluation version of : vhost-net over SRIOV using
macvtap. Wondering if there were any preliminary performance studies done (i.e.
i/o performance in the guest and also host cpu cycles consumption) between the
following configurations :
1) vhost-net over
On 03/29/2012 04:35 PM, Michal Suchanek wrote:
On 29 March 2012 11:35, Avi Kivity a...@redhat.com wrote:
On 03/28/2012 07:44 PM, Michal Suchanek wrote:
Hello,
On 28 March 2012 19:02, Avi Kivity a...@redhat.com wrote:
0:0f 2b 07 movntps %xmm0,(%edi)
3:
On 03/29/2012 01:56 PM, Jan Kiszka wrote:
On 2012-03-27 18:39, Anthony Liguori wrote:
On 03/27/2012 11:22 AM, Jan Kiszka wrote:
On 2012-03-27 17:59, Avi Kivity wrote:
On 03/27/2012 11:55 AM, Jan Kiszka wrote:
On 2012-03-27 10:55, Vasilis Liaskovitis wrote:
Hi,
is live migration
On 03/29/2012 10:17 AM, Avi Kivity wrote:
On 03/29/2012 01:56 PM, Jan Kiszka wrote:
On 2012-03-27 18:39, Anthony Liguori wrote:
On 03/27/2012 11:22 AM, Jan Kiszka wrote:
On 2012-03-27 17:59, Avi Kivity wrote:
On 03/27/2012 11:55 AM, Jan Kiszka wrote:
On 2012-03-27 10:55, Vasilis Liaskovitis
On Thu, 29 Mar 2012 11:44:12 +0200
Avi Kivity a...@redhat.com wrote:
Even without using reverse mapping we can restrict that flush easily:
http://www.spinics.net/lists/kvm/msg68695.html
[PATCH] KVM: Avoid zapping unrelated shadows in
__kvm_set_memory_region()
This would be
On 03/27/2012 12:42 PM, Jan Kiszka wrote:
On 2012-03-27 18:49, Anthony Liguori wrote:
On 03/27/2012 11:46 AM, Avi Kivity wrote:
On 03/27/2012 06:39 PM, Anthony Liguori wrote:
So, since we're approaching 1.1, we should really discuss release
criteria for 1.1 with respect to live migration.
On 03/29/2012 05:21 PM, Anthony Liguori wrote:
Option 1: make -M old force an old vmstate to be written out. Sounds
like a generally useful thing.
Option 2: ask those consumers to issue updates that bring their code up
to version 3. Require fully updated qemus on both sides. Easy to
On 03/29/2012 05:21 PM, Takuya Yoshikawa wrote:
On Thu, 29 Mar 2012 11:44:12 +0200
Avi Kivity a...@redhat.com wrote:
Even without using reverse mapping we can restrict that flush easily:
http://www.spinics.net/lists/kvm/msg68695.html
[PATCH] KVM: Avoid zapping unrelated shadows
On 03/29/2012 03:10 PM, Avi Kivity wrote:
On 03/29/2012 11:23 AM, Xiao Guangrong wrote:
Do not use the last byte (bit 56 ~ bit 63) in shadow_mmio_mask, the late
patch will store vcpu id in the last byte
Bit 63 is PT64_NX_MASK.
Oh, you did say that with softmmu we're limited to 127 cpus.
On Thu, 29 Mar 2012 17:26:59 +0200
Avi Kivity a...@redhat.com wrote:
Hm, the patch uses -slot_bitmap which we might want to kill if we
increase the number of slots dramatically, as some people want to do.
btw, what happened to that patch, did it just get ignored on the list?
I
On Wed, Mar 28, 2012 at 07:47:31PM +0200, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited
On 2012-03-29 17:39, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 07:47:31PM +0200, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on
On 03/29/2012 11:25 AM, Xiao Guangrong wrote:
Using PTE_LIST_WRITE_PROTECT bit in rmap store the write-protect status to
avoid unnecessary shadow page walking
Does kvm_set_pte_rmapp() need adjustment?
Also if no shadow page is indirect, the page is write-free
+ if
On 2012-03-29 17:23, Anthony Liguori wrote:
On 03/27/2012 12:42 PM, Jan Kiszka wrote:
On 2012-03-27 18:49, Anthony Liguori wrote:
On 03/27/2012 11:46 AM, Avi Kivity wrote:
On 03/27/2012 06:39 PM, Anthony Liguori wrote:
So, since we're approaching 1.1, we should really discuss release
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user space as to manage
carefully.
By providing a
On 03/29/2012 05:28 PM, Avi Kivity wrote:
On 03/29/2012 03:10 PM, Avi Kivity wrote:
On 03/29/2012 11:23 AM, Xiao Guangrong wrote:
Do not use the last byte (bit 56 ~ bit 63) in shadow_mmio_mask, the late
patch will store vcpu id in the last byte
Bit 63 is PT64_NX_MASK.
Oh, you did
On Thu, Mar 29, 2012 at 06:15:41PM +0200, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited
On 2012-03-29 18:46, Michael S. Tsirkin wrote:
On Thu, Mar 29, 2012 at 06:15:41PM +0200, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on
On 03/29/2012 03:28 PM, Avi Kivity wrote:
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
Looks like a good baseline on which to build the KVM
implementation. We
might need some handshake to prevent interference on the host
side with
the PLE
On 2012-03-29 18:15, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user space has to manage
carefully.
By providing a
On Thu, Mar 29, 2012 at 09:14:12PM +0200, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited
When using device assignment, new page mappings are added to the iommu,
but never removed. Fix it. We're also lazy about tearing down the
iommu and unpinning the guest when we have no assigned devices attached.
Instead of waiting for the vm to be destroyed, do these cleanups when
we deassign the
We've been adding new mappings, but not destroying old mappings.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
include/linux/kvm_host.h |6 ++
virt/kvm/iommu.c |7 ++-
virt/kvm/kvm_main.c |5 +++--
3 files changed, 15 insertions(+), 3
Unpin the guest and free the iommu domain if there are no longer
any devices attached.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
virt/kvm/assigned-dev.c |3 +++
virt/kvm/iommu.c|1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git
On Thu, Mar 29, 2012 at 9:15 PM, Federico Fanton feder...@panizzolo.it wrote:
Hi everyone!
We have an Hylafax 5.2.5 CentOS 5 installation hosted inside a Xen virtual
machine. It works quite well, but now I'm in the process of
upgrading/migrating it to a KVM virtual machine running Ubuntu
Hi Paolo,
The same bug I found in v3 is still in v5. please refer to this mail:
https://lkml.org/lkml/2012/3/10/207
--
Thanks,
Hu Tao
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Benchmark shows small performance improvement on fusion io device.
Before:
seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec
rnd-read : io=1,024MB, bw=15,404KB/s, iops=30,808, runt= 68070msec
rnd-write:
The Buildbot has detected a new failure on builder next-x86_64 while building
kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-x86_64/builds/487
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly
The Buildbot has detected a new failure on builder next-i386 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-i386/builds/487
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly
On 03/29/2012 09:00 PM, Avi Kivity wrote:
On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
Split FNAME(prefetch_invalid_gpte) to check gpte independently which will
be used in the later patch
-static bool FNAME(prefetch_invalid_gpte)(struct kvm_vcpu *vcpu,
-
On Tue, Mar 27, 2012 at 01:34:43PM -0600, Alex Williamson wrote:
[snip]
this case, it gets a bit complex. When the FooBus isolation provider
is active, the FooBus devices would be in their own groups, not the
group of the FooBridge and its sibling. When the FooBus isolation
On 03/29/2012 09:07 PM, Avi Kivity wrote:
On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
It can calculate the base gpa of the specified shadow page on any level,
let it instead of FNAME(get_level1_sp_gpa)
+static gpa_t FNAME(get_sp_gpa)(struct kvm_mmu_page *sp)
+{
Maybe worth adding a
On 03/29/2012 11:49 PM, Avi Kivity wrote:
On 03/29/2012 11:25 AM, Xiao Guangrong wrote:
Using PTE_LIST_WRITE_PROTECT bit in rmap store the write-protect status to
avoid unnecessary shadow page walking
Does kvm_set_pte_rmapp() need adjustment?
Yes, in kvm_set_pte_rmapp(), if the page is
On 03/28/2012 11:04 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote:
Ah, then it's not a guest problem, it's how the chip was designed.
Newer chips do allow a workaround (GR31 bit 6):
6 System Source Location (Revision A): If this bit is ‘1’, the
On 03/29/2012 07:15 AM, Takuya Yoshikawa wrote:
On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity a...@redhat.com wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse
On Thu, 2012-03-29 at 11:36 +0200, Avi Kivity wrote:
In any case, X seems to avoid it, maybe nobody does color expansion
nowadays (I suppose modern desktops don't, maybe using ancient X apps
might trigger that path). So no biggie. I'll have to fix KVM powerpc
dealing with memslot changes
Hi,
As a workaround you can use -vga std or -vga qxl. The latter will work
even better when we have a kernel driver.
There is a kernel driver for -vga std too ;)
http://patchwork.ozlabs.org/patch/145479/
Didn't try on ppc though. There is a funky #ifdef TARGET_I386 in
vbe_portio_list[],
On 03/29/2012 05:21 PM, Takuya Yoshikawa wrote:
On Thu, 29 Mar 2012 11:44:12 +0200
Avi Kivity a...@redhat.com wrote:
Even without using reverse mapping we can restrict that flush easily:
http://www.spinics.net/lists/kvm/msg68695.html
[PATCH] KVM: Avoid zapping unrelated shadows
On Thu, 29 Mar 2012 17:26:59 +0200
Avi Kivity a...@redhat.com wrote:
Hm, the patch uses -slot_bitmap which we might want to kill if we
increase the number of slots dramatically, as some people want to do.
btw, what happened to that patch, did it just get ignored on the list?
I
77 matches
Mail list logo
