On Sat, Feb 10, 2007 at 02:52:16PM +0100, Andi Kleen wrote:
> On Saturday 10 February 2007 14:43, Muli Ben-Yehuda wrote:
> > On Sat, Feb 10, 2007 at 12:42:48PM +0100, Andi Kleen wrote:
> > >
> > > I will post the existing patches in batches for closer review.
>
On Mon, Feb 12, 2007 at 09:14:25AM +0100, Arjan van de Ven wrote:
> Xen the linux guest
> or
> Xen the hypervisor?
>
> if it's the later, why on earth would we want to uglyfy linux for it?
> (arguably it holds in the former case as well)
Xen the hypervisor (i.e., do
rray)); (index)++)
Could we please stop "improving" the C language? it has served us fine
so far.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Likewise IOMMUs.
I think Andrew's suggestion of adding a CFP phase to KS is excellent -
get some new blood in the room and spice up the discussion.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
due to bad things
> falling from the sky in Israel at the time ?
That was OLS, not KS. Also, that's not the impression I got from
reading the lwn.net summary (and I know several IOMMU people such as
Olof were not invited... I think it was just jejb and ak?).
Cheers,
Muli
-
To unsubscrib
ed */
> static u32 mmcfg_last_accessed_device;
>
> -static DECLARE_BITMAP(fallback_slots, MAX_CHECK_BUS*32);
> +extern DECLARE_BITMAP(pci_mmcfg_fallback_slots, MAX_CHECK_BUS*32);
... and this (also occurs in another place).
Cheers,
Muli
-
To unsubscribe from this list: send the lin
s);
> + printk(KERN_INFO "PCI: Using MMCONFIG at %x-%x\n",
> pci_mmcfg_config[i].base_address, pci_mmcfg_config[i].base_address + size -
> 1);
80 chars per line please...
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Dec 07, 2006 at 04:19:41PM +0100, Olivier Galibert wrote:
> On Thu, Dec 07, 2006 at 05:00:23PM +0200, Muli Ben-Yehuda wrote:
> > On Thu, Dec 07, 2006 at 03:49:53PM +0100, Olivier Galibert wrote:
> >
> > > +void __init pci_mmcfg_init(int type)
>
supported
> way before that.
If I was bored, I might've counted how many /* */ style comments we
had in the source, then used it to construct an elaborate argument why
C++-style comments are evil and Conformance is Goodness, but I'm not,
so I won't.
Cheers,
Muli
-
To unsubscribe
sys_munlock':
> (.text+0xcaf1): undefined reference to `_proxy_pda'
> mm/built-in.o:(.text+0xcc11): more undefined references to `_proxy_pda' follow
> make: *** [.tmp_vmlinux1] Błąd 1
>
> Something related (git tree fetched 1-2h ago) ?
Probably. Please send your .con
On Fri, Dec 08, 2006 at 02:03:12PM +0100, Arkadiusz Miskiewicz wrote:
> On Friday 08 December 2006 13:51, Muli Ben-Yehuda wrote:
> > On Fri, Dec 08, 2006 at 01:04:23PM +0100, Arkadiusz Miskiewicz wrote:
> > > On Friday 08 December 2006 04:01, Andi Kleen wrote:
> > >
On Sun, Dec 10, 2006 at 06:59:10AM +1100, Benjamin Herrenschmidt wrote:
> I'd really like to have some kind of macro or attribute or whatever I
> can put on a function call to say that I'm purposefully ignoring the
> error. Is there some gcc magic that can do that ?
(void)b
ls?
I have a Nokia E61, I'll try to reproduce it when I'll have a few free
moments.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
W: It would be really great if this area of the kernel would get some
> more and better documentation. The information at
> linux-2.6/Documentation/x86_64/boot_options.txt is very terse. I had to
> read the code to get a *rough* idea what all the "iommu=" options
> actually do
ly), as
the IOMMU in use should be transparent to the driver. Which driver is
it?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
g Calgary in should make no
difference, as we detect in run-time which IOMMU is found and the
machine.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
ed to use right
now)).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Dec 14, 2006 at 02:52:35AM -0700, Erik Andersen wrote:
> On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote:
> > > I just realized that booting with "iommu=soft" makes my pcHDTV
> > > HD5500 DVB cards not work. Time to go back to disabling th
On Thu, Dec 14, 2006 at 12:38:08PM +0100, Karsten Weiss wrote:
> On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
>
> > On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
> >
> > > BTW: It would be really great if this area of the kernel would get some
> >
On Thu, Dec 14, 2006 at 02:16:31PM +0100, Karsten Weiss wrote:
> On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
>
> > The rest looks good. Please resend and I'll add my Acked-by.
>
> Thanks a lot for your comments and suggestions. Here's my 2nd try:
>
> ==
while back but it
> doesn't seem to have been applied. it's possible it's still in the
> queue somewhere but it seems unlikely at this point.
The OSS subsystem doesn't have an overall maintainer, for patches like
this you should probably CC akpm (CC'd). Also, ack on
t actually happened, I'm betting your machine has both
Calgary and CalIOC2, the PCI-e version of Calgary, which is not yet
supported by pci-calgary.c. I have a patch for CalIOC2 which is work
in progress and not ready for inclusion yet. Can you please send lspci
-v to confirm?
Cheers,
Muli
*((unsigned short *)(ptr + offset));
> }
> if (!rio_table_hdr) {
> -
Patch looks good to me, thanks. I'll give it a spin to verify.
Please CC me on Calgary patches.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Wed, Dec 20, 2006 at 01:34:15PM +0200, Muli Ben-Yehuda wrote:
> On Wed, Dec 20, 2006 at 11:53:32AM +0100, Ingo Molnar wrote:
[snipped patch]
> Patch looks good to me, thanks. I'll give it a spin to verify.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Andi, I assume
.g.,
http://ozlabs.org/pipermail/k42-discussion/2006-October/001615.html.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
be able to hack around using
> kprobes if you really need (but then again for a mission critical system
> you should have proper active-active failover clustering anyway)
I'm not advocating we merge this - nor have I seen the implementation
for Linux yet - no need to preemptively scor
If no one is looking after them, shouldn't they just be removed?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
said people
might be inclined to start maintaining it. We have a bar for inclusion
of new code into the tree - why shouldn't a quality bar also be
applied to old code in the tree?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
and for kexec case, the first kernel already
> enable that, the memset in second kernel will cause the system
> restart. So disable that at first before we try to allocate mem for
> it.
Why does the memset in the second kernel cause a system restart?
Cheers,
Muli
-
To unsubscribe from
rent address spaces for different devices? (e.g., Calgary which
is in mainline, Intel's VT-d which is coming soon, etc).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nd.
>
> current I only test kexec only. So clean shut GART in first kernel will
> help.
>
> where is hook for shutdown? add one in dma_ops?
I was wondering the same thing. I think it should hook into the
standard device model. It definitely should *not* be in the dma_ops
(it has no
about we do
struct iommu_ops {
struct dma_ops {
...
}
void (*shutdown)(void);
}
And then pci_iommu_shutdown() becomes
if (iommu_ops->shutdown)
iommu_ops->shutdown();
?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
own
> handler in sysfs Don't see any value in going through a generic
> layer because there is no shared code.
Going through the shared layer makes it obvious to new IOMMU
implementers that they will need to implement a shutdown hook and
takes roughly the same ammount of work. I think th
ile if !CONFIG_IOMMU. That's quite standard kernel practice and
> >might help avoid some other problems...
>
> move ifdef into gart_iommu_shudown()?
What Andrew means is
(in a header file)
#ifdef CONFIG_IOMMU
extern void gart_iommu_shutdown(void);
#else
static inline void gart_iommu
ommu_detected;
> #ifdef CONFIG_IOMMU
> extern void gart_iommu_init(void);
> +extern void gart_iommu_shutdown(void);
> extern void __init gart_parse_options(char *);
> extern void iommu_hole_init(void);
> extern int fallback_aper_order;
> @@ -101,6 +103,11 @@ extern int fix_apertur
On Mon, Jun 25, 2007 at 12:52:48PM -0700, Yinghai Lu wrote:
> >I suggest include/asm-x86_64/iommu.h for this. proto.h doesn't have
> >anything to do with it.
>
> move iommu releated to iommu.h and add iommu_ops struct?
That's how I would do it, to complement dma_m
interesting to see comparable numbers for VT-d.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ink an iommu_ops is a better approach. I'll put
something together when I add the Calgary shutdown bits next week
after OLS.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
for having other users of sysdata, such as
the PCI domains work.
The Calgary bits are tested, the NUMA bits just look ok.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/i386/pci/acpi.c | 32 +
On Wed, Jul 11, 2007 at 09:41:59AM -0700, Yinghai Lu wrote:
> Muli Ben-Yehuda wrote:
> >Andi, please consider applying for 2.6.23. Applies on top of the
> >Calgary update I just sent out ("Calgary: more updates for 2.6.23").
> >
> >This patch introduces stru
On Thu, Jul 12, 2007 at 09:17:31AM +0800, Arjan van de Ven wrote:
> On Wed, 2007-07-11 at 16:45 +0300, Muli Ben-Yehuda wrote:
> > Andi, please consider applying for 2.6.23. Applies on top of the
> > Calgary update I just sent out ("Calgary: more updates for 2.6.23").
>
and code churn, I also don't like teaching every
architecture about every other architecture's use of sysdata, which is
inherently architecture specific. I think the benefits of modularity
here outweigh the benefits of a little type safety.
Cheers,
Muli
-
To unsubscribe from this
xing -- it should not try to bounce when the normal
> kernel wouldn't.
Xen needs to bounce when the requested buffer is not contiguous in
machine memory (and indeed uses swiotlb for that).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
#x27;t boot without it
if CONFIG_CALGARY_IOMMU is enabled).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > The Xen and Calgary bits are mutually exclusive, so hopefully (a)
> > will not be held up on account of the Xen merge (or for any other
> > reason... CalIOC2 machine
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> >
> > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> >
> > > > The Xen a
gt; #endif
The generic bits look much better than the previous version,
thanks. Is the generic dma_data_direction_set_dmaflush really needed?
if yes, what about dma_data_direction_get_direction and
dma_data_direction_get_dmaflush?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
OTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI
of chained sglists once
> that happens.
I sincerely hope they'll make 2.6.23 but Andi appears to have fallen
into a black hole.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
finiband driver interfaces so that you can get at the
> buffer or provide some other mechanism by which you can accomplish
> what you're trying to do.
AFAICR the ipath driver had the same problem, which resulted in the
addition of ib specific DMA-API wrappers. See usage of struct
ipath_d
On Mon, Jun 04, 2007 at 03:06:54PM -0400, Jeff Garzik wrote:
> On Mon, Jun 04, 2007 at 11:33:44AM -0700, Andrew Morton wrote:
> > On Tue, 22 May 2007 04:05:54 -0400
> > [EMAIL PROTECTED] wrote:
> >
> > > From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
> >
o it.
Also, FWIW, we don't use the same pointer for different uses (that
wouldn't have worked, obviously) but I've never been 100% comfortable
with the hack we use and this is obviously the right thing to do.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscri
On Tue, Jun 05, 2007 at 01:29:05PM +0300, Muli Ben-Yehuda wrote:
> On Mon, Jun 04, 2007 at 05:05:51PM -0400, Jeff Garzik wrote:
> >
> > This patch introduces struct pci_sysdata to x86 and x86-64, and
> > converts the existing two users (NUMA, Calgary) to use it.
> &g
patch and I kept it since it's
obviously harmless (without CONFIG_PCI_DOMAINS pci_domain_nr() is
defined to 0).
> No objection, obviously, and it's obviously safe given that
> CONFIG_PCI_DOMAINS is not defined on x86/x86-64.
>
> Nonetheless, it appears "off-topic" fo
ping is
> needed.
Calgary already does this internally (via calgary=disable=)
but that's pretty ugly. It would be better to do it in a generic
fashion when deciding which dma_ops to call (i.e., a dma_ops per bus
or device).
> Also the user interface for X server case needs more work.
Is
On Tue, Jun 26, 2007 at 08:03:59AM -0700, Arjan van de Ven wrote:
> Muli Ben-Yehuda wrote:
> >How much? we have numbers (to be presented at OLS later this week)
> >that show that on bare-metal an IOMMU can cost as much as 15%-30% more
> >CPU utilization for an IO intensive w
hernet cards.
Please try netperf and a bigger machine for a meaningful comparison :-)
I assume this is with e1000?
> Going forward we will do more benchmark tests and will share the
> results.
Looking forward to it.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscri
On Wed, Jun 27, 2007 at 10:41:21AM -0700, Yinghai Lu wrote:
> [PATCH] x86_64: change _map_single to static in pci_gart.c etc
>
> there function is called via dma_ops->.., so change it to static
Thanks, mostly looks good - will verify and push via the next set of
Calgary updates.
that block and net IOs will not straddle a page
boundary?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jun 27, 2007 at 04:21:10PM -0400, Muli Ben-Yehuda wrote:
> On Wed, Jun 27, 2007 at 10:41:21AM -0700, Yinghai Lu wrote:
> > [PATCH] x86_64: change _map_single to static in pci_gart.c etc
> >
> > there function is called via dma_ops->.., so change it to static
>
asm-x86_64/dma_mapping.h to
> arch/x86_64/pci-dma.c?
If yes, why? it's not exactly a big function:
static inline dma_addr_t
dma_map_single(struct device *hwdev, void *ptr, size_t size,
int direction)
{
BUG_ON(!valid_dma_direction(direction));
return dma_ops->
return 0;
The convention is to print a KERN_DEBUG message if hardware is not
found when probing it, otherwise the boot messages become cluttered
with lots of "$FOO not found".
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;re right, that should be a debug message as well.
> [..]
> Calgary: detecting Calgary via BIOS EBDA area
> Calgary: Unable to locate Rio Grande table in EBDA - bailing!
These are KERN_DEBUG messages.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-
a
different structure) so ...
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
x27;ll push it out with the next Calgary update.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the user need to provide a command line option to specify the graphics
adapter?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
quot;);
> + return 0;
> }
This pretty much duplicates the checking done in
arch/x86-64/kernel/aperture.c:aperture_valid(), with slight variations
(e.g., 32MB vs. 64MB aperture size). Should these two functions be
consolidated?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y used by IOMMU driver to
> keep its per device context pointer.
Hmpf, why is this needed? with the pci_sysdata work that recently went
into mainline we have a void *iommu member in pci_sysdata which should
be all that's needed. Please elaborate if it's not enough for your
needs.
Thanks,
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
> On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
> > On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
> >
> > > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early c
atch solves my problem.
> Any objection to below patch?
I will give it a spin to verify it works for me, but in general I am
wary of making such changes unless we can verify (read: audit) that
they have no adverse side effects *on all architectures*.
Cheers,
Muli
-
To unsubscribe from this li
0x1fffULL
> -#define DMA_28BIT_MASK 0x0fffULL
> -#define DMA_24BIT_MASK 0x00ffULL
> +#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
> +
> +#define DMA_64BIT_MASK DMA_BIT_MASK(64)
This one does not do what you mean. You need an explic
The old check we used based on dev->bus->number is wrong for devices
on CalIOC2. Instead look whether we have an IOMMU table for that bus -
if not, translation is disabled.
Thanks to Murillo Fernandes Bernardes <[EMAIL PROTECTED]> for
spotting, suggesting a fix and testing.
Signed-
Now that we check for translation enabled/disabled based on the
presence of the IOMMU translation table, we can get rid of
translate_phb.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
pci-calgary.c | 31 +++
1 files changed, 15 insertions(+), 16 del
On Wed, Aug 22, 2007 at 11:56:22PM +0200, Thomas Gleixner wrote:
> We are pleased to announce v2 of the unified arch/x86 project we are
> working on.
After having recently inadvertently broken i386 while making x86-64
changes, thumbs up from me!
Cheers,
Muli
-
To unsubscribe from thi
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
> Hi, Muli
>
> saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> could get rid of saved_max_pfn at all. But If this can't work, how
> about exporting a calgary tce table size to user space, so th
On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote:
> OK, second question... is it time to axe Calgary?
I don't know of anyone still using it, but it's not
impossible. Calgary and CalIOC2 machines would now be ~5-8 years old.
Cheers,
Muli
--
To unsubscribe from this l
o move
> it to drivers/iommu?
Not sure I see the potential benefit... I think for Calgary it's
either leave it in arch/x86 or rip it out.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
aved_max_pfn completely.
If this is not too painful then this would be my preference too.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
Patch looks good to me.
Acked-by: Muli Ben-Yehuda
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
's log file inside ESXi and you
will likely find some errors related to running nested, MSRs KVM does
not emulate properly, or something else that causes ESXi to use binary
translation for its L2.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
L2, it should have a lot more
information.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
101 - 181 of 181 matches
Mail list logo
